A First Look at Java 10 Release Candidate 1

Scheduled for a GA release on March 20, 2018, Java 10 RC1 is now available for the Java community. This will be the first upgrade that will follow Oracle's new six-month release cycle. Earlier this month, the proposed final draft of Java 10 (18.3) (JEP 383) was published and recently entered into the final release candidate phase as per the proposed schedule.

As specified in the release candidate document, the specific goals are to:

• Fix all P1 bugs that are new in JDK 10 and critical to the success of the release;
• Decommit from fixing any P1 bugs that are not new in JDK 10 and are not critical to this release, but were previously targeted to this release; and
• Explicitly defer any P1 bugs that are new in JDK 10 but are either not critical to this release or cannot, for good reason, be fixed in this release.

Any bugs categorized as P2 through P5 bugs will be addressed in future releases, regardless of their status in product code, tests, or documentation.

As reported by InfoQ last November, some of the new features of Java 10 have already been in development for some time. Developers can expect the following:

• JEP-286: Local-Variable Type Inference
• JEP-296: Consolidate the JDK Forest into a Single Repository
• JEP-304: Garbage-Collector Interface
• JEP-307: Parallel Full GC for G1
• JEP-310: Application Class-Data Sharing
• JEP-312: Thread-Local Handshakes
• JEP-313: Remove the Native-Header Generation Tool (javah)
• JEP-314: Additional Unicode Language-Tag Extensions
• JEP-316: Heap Allocation on Alternative Memory Devices
• JEP-317: Experimental Java-Based JIT Compiler
• JEP-319: Root Certificates
• JEP-322: Time-Based Release Versioning

JEP-286: Local-Variable Type Inference

The most intriguing and anticipated feature in Java 10 is local-variable type inference that introduces the new reserved type name, var. It is now possible to write the following code:

    
var x = 10;
var y = 20;
var z = application.getSum(x,y);

public int getSum(int x,int y) {
    return x + y;
    }

var list = new ArrayList<String>();
list.add("Hello!");
list.add("World!");
    

var may only be used in:

• local variables with initializers
• for-loop indices
• the local scope of a conditional loop.

var may not be used in parameter lists and as a return types. Therefore, the following code will not compile:

    
public int passByVar(var y) {
    return y;
    }

public var returnVar(int y) {
    return y;
    }
    

More code examples can be found on GitHub.

Based on the results of two surveys conducted by Oracle in early 2016, developers were in favor of a local-variable type inference mechanism. However, their main concern was over readability as discussed in the survey summary:

For example, code like the following strawman was offered by several commenters:

    
var x = y.getFoo()
    

as evidence of "see, its unreadable, you have no idea what 'x' is." The readability problem here, though, stems from the fact that 'x' is just a poorly chosen variable name. Having a manifest type might make up for the programmer's laziness, but it would be better to just choose a good variable name in the first place.

While every situation may be different, we believe that, with judicious use of this feature in well-written code, readability is actually *enhanced*. Consider a block of locals:

    
UserModelHandle userDB = broker.findUserDB();
List<User> users = db.getUsers();
Map<User,Address> addressesByUser = db.getAddresses();
    

What is the most important thing on each line, the variable *name*, the variable *type*, or the initializing expression? We claim it is the name that is most important -- because they describe the role of the variable *in the current program*. And the variables names are not so easy to visually pick out from the above code -- they're stuck in the middle of each line, and at a different place on each line.

Ideally, we'd like for the most important thing to be front-and-center in the reader's view. If we rewrite the above block with inferred types:

    
var userDB = broker.findUserDB();
var users = db.getUsers();
var addressesByUser = db.getAddresses();
    

the true intent of this code pops out much more readily; the variable names are (almost) front and center. The lack of manifest types is not an impediment, because we've chosen good variable names.

Improved Garbage Collection

JEP-304 introduces a new garbage collector interface. As reported by InfoQ:

It will be easier for vendors to produce JDK builds that contain, or exclude a specific GC algorithm. With new GC approaches such as Shenandoah, ZGC and Epsilon in development, then this makes sense. There are even efforts within the community to deprecate and even remove the Concurrent-Mark-Sweep collector (CMS) although at present there is no production-quality feasible replacement for it.

JEP-307 solves a problem with the G1 garbage collector that, as of Java 9, uses a single-threaded algorithm. InfoQ also stated:

This means that if G1 ever has to fall back to a full GC then a nasty performance shock awaits. The aim of JEP 307 is to parallelize the full GC algorithm so that in the unlikely event of a G1 Full GC then the same number of threads can be used as in the concurrent collections.

Features Removed

The utility, javah, has officially been removed. The motivation, as stated in JEP-313, explains:

The tool has been superseded by superior functionality in javac, added in JDK 8 (JDK-7150368). This functionality provides the ability to write native header files at the time that Java source code is compiled, thereby eliminating the need for a separate tool.

Focusing on the support provided by javac eliminates the need to upgrade javah to support recent new paradigms, such as API access via the Compiler API in javax.tools.*, or the new java.util.spi.ToolProvider SPI added in JDK 9.

Mandy Chung, principal member of the technical staff at Oracle, recently posted a proposal on OpenJDK to finally remove the Runtime.runFinalizersOnExit() and System.runFinalizersOnExit() methods for JDK 11 as they have been deprecated since Java 1.2. These methods have been deemed unsafe as calls to finalizers on live objects while other threads are concurrently manipulating those objects may result in erratic behavior or deadlock.

Details on all new features and ones that will be removed can be found on the release notes.

Resources

• Java to Move to 6-Monthly Release Cadence by InfoQ (September 6, 2017)
• Java 10 Sneak Peek: Local-Variable Type Inference (var)! By Adrian Finlay (November 14, 2017)
• Java 10 - The Story So Far by InfoQ (November 21, 2017)
• Inspired by Actual Events by Dustin Marx (February 1, 2018)