With the recent release of Java Development Kit (JDK) 9, a great deal of attention has been rightfully focused on the newest features of Java, including the introduction of modules (through the incorporation of Project Jigsaw). Although much of the recent attention has been devoted to these powerful new features, work has already begun on the next release of Java: JDK 10. In this article, we will take a cursory look at the major features slated for JDK 10, as well as explore some of the features for JDK 10 that may be included in JDK 10 down the road.

Note that the world of JDK 10 is changing fast and the information contained in this article is intended to be accurate at the time of writing. The JDK 10 feature group is expected to increase and the proposals for features are likely to grow before JDK 10 is finally released.

New Features

Just as with previous JDK releases, there are some major features coming to JDK 10. These features can be broken up into two principal categories: (1) targeted for release and (2) proposed for release. The former category constitutes those features that have taken on a great deal of traction and have been scheduled for release with JDK 10. The latter category are those features that have gained momentum and require increased support and maturity prior to being included in JDK 10. Once a feature in this latter category has gained these prerequisites, it may be upgraded to a targeted for release status.

Targeted for Release

There are currently two major features that are targeted for JDK 10: (1) local variable type inference, which will remove a large portion of the tedious inclusion manual type information required for object instantiation, and (2) consolidation of the source tree for the JDK repositories, whereby the various JDK repositories will be combined into a single repository.

1. Local Variable Type Inference

Strongly-typed programming languages have many advantages, including the discovery of type errors at compile time, but they also introduce a great deal of boilerplate code, especially when defining local variables. For example, when we wish to instantiate an object, we are forced to provide the manifest type on the left side of the initialization assignment as well as the implementation type on the right side of the assignment, as seen in the following snippet:

MyObject value = new MyObject();

When this process is repeated for a large number of assignments, object instantiation can become both frustratingly cumbersome and tedious. Many of the most popular strongly-type programming languages, such as C++, C#, and Go provide a means of inferring the type of a local variable during definition (e.g. C++ provides the auto keyword and C# provides the var keyword). Java, on the other, still lacks such functionality, requiring that developers explicitly declare the intended manifest type for a variable. In order to resolve this issue, Java Development Kit (JDK) Enhancement Proposal (JEP) 286 proposes a context-sensitive keyword, var, that allows for local variables to be initialized in the following manner:

var value = new MyObject();
var list = new ArrayList<MyObject>();

Since the var keyword is context-sensitive, the following rule is defined for its use:

Code that uses var as a variable, method, or package name will not be affected; code that uses var as a class or interface name will be affected

Likewise, type inference is slated to be constrained in the following manner:

[Infered types will] be restricted to local variables with initializers, indexes in the enhanced for-loop, and locals declared in a traditional for-loop; it [will] not be available for method formals, constructor formals, method return types, fields, catch formals, or any other kind of variable declaration.

All restrictions and nuances considered, this feature will help alleviate a large deal of monotony in developer-created application Java code as well as simplify the JDK code base (updates will be made to the JDK to update variable definitions to use inferred types where possible). More information can be found in the official JEP 286 specification.

2. Consolidation of JDK Repositories

Currently, there are 8 separate Mercurial repositories used to store the large volume of source code that comprises the JDK: (1) root, (2) corba, (3) hotspot, (4) jaxp, (5) jaxws, (6) jdk, (7) langtools, and (8) nashorn. While this plethora of repositories provides a clear separation of concerns for the various components that make up the JDK, there are some major disadvantages to managing numerous repositories.

Foremost among these is the inability of a single bug fix to be atomically tracked across two different parts of the JDK. For example, if a single bug fix requires changes to two parts of the system contained in separate repositories, two commits must be made: One in each of the repositories. This discontinuity can easily lead to reduced tractability and increased complexity for project and source code management tools.

In order to resolve this issue, JEP 296 proposes that all of the existing repositories be combined into a single Mercurial repository. A secondary effect of this consolidation is that this single Mercurial repository can also be mirrored (as a Git repository) much more easily than the eight existing repositories. While there has been some pushback from outside developers on this consolidation process, it appears as that the JDK development team has committed to making this change a part of JDK 10. For more information, see JEP 296 and Proposed Consolidation of JDK 10 OpenJDK Mercurial Repositories announcement published by Michael Redlich.

Proposals for Release

In addition to two targeted features, JDK 10 currently has three proposals–two of which focus on upgrades to the garbage collector portion of the JDK and one focusing on upgrades to the thread-local functionality of the JDK.

1. Cleaner Garbage Collection Interface

In the current JDK structure, the components that make up a Garbage Collector (GC) implementation are scattered throughout various parts of the code base. While these conventions are well known to those familiar with the GC scheme used by the JDK, it is often confusing for newer developers to find the source code for a specific GC or to create a new one. Whatsmore, with the advent of modules in Java, it is desirable to exclude unneeded GCs from the build process, but the current cross-cutting structure of the GC interface precludes such enhancements.

JEP 304 was devised as a solution to this problem and proposes to consolidate as well as clean up the GC interface, allowing for easier implementation of new GCs and for better maintenance of existing GCs. After the completion of this proposal, a GC implementation would be responsible for providing the following:

• The heap, a subclass of CollectedHeap
• The barrier set, a subclass of BarrierSet, which implements the various barriers for the runtime
• An implementation of CollectorPolicy
• An implementation of GCInterpreterSupport, which implements the various barriers for a GC for the interpreter (using assembler instructions)
• An implementation of GCC1Support, which implements the various barriers for a GC for the C1 compiler
• An implementation of GCC2Support, which implements the various barriers for a GC for the C2 compiler
• Initialization of eventual GC specific arguments
• Setup of a MemoryService, the related memory pools, memory managers, etc.

For more information on these changes, see the JEP 304 specification; for more information on the GC in Java, see the Garbage Collector Basics guide provided by Oracle.

2. Parallelization of G1 Garbage Collector

With the release of JDK 9, the Garbage-First (G1) GC replaced the Parallel Collector as the default GC. In order to reduce the impact of garbage collection in JDK releases beyond JDK 9, the G1 collector is slated to be parallelized (to match the characteristics of the Parallel Collector). While there is little information on the implementation details of this parallelization to date, more detail on this change can be found in the JEP 307 specification. For more information on GC implementations in general, see the G1 guide and Parallel Collector guide from Oracle.

3. Thread-Local Handshakes

Currently, stopping a Java thread is an all-or-nothing process requiring a Java Virtual Machine (JVM) safepoint to be reached in order for a single thread to be stopped. In order to allow for individual threads to be stopped, JEP 312 proposes the inclusion of callbacks for threads. This change is restricted from appreciably increasing the performance overhead of existing JVM functionality and from altering the existing temporal semantics of reaching a JVM global safepoint. For more information on this proposal, see the Thread-Local Handshake OpenJDK discussion on JEP 312.

Conclusion

Although the release of JDK 9 is fresh in the minds of many Java developers, the work does not halt on future releases of the JDK. In particular, JDK 10 promises to introduce type inference mechanism for local variable instantiation and consolidate the existing JDK repositories into a single Mercurial repository. In addition, with more maturity and support, JDK 10 may also include some important upgrades to the GC interface and the default GC implementation, as well as upgrades to the addressability of individual threads in the JVM. While the release of JDK 10 is still relatively far in the future, and the features included are very likely to increase, it has already promised to bring a lot to the table and will likely be an important milestone in the Java timeline.