It has been exactly two months since the release of Java 9, so as per the new schedule, the next release of Java is now only four months away. The complete scope for Java 10 is still being confirmed and locked down. This means that there is still the possibility of significant changes to the scope and content of the release between now and the GA data. However, it is possible to get some idea of what features developers can reasonably expect to arrive with Java 10, in around four months time.
New features and enhancements are tracked through either the Java Enhancement Process as JEPs, or through the Java Community Process for standardization requests (JSRs). With the short timescale and accordingly small scope, Java 10's changes will be arriving as JEPs and can be tracked via their JEP number.
The features that Java 10 seems most likely to contain are those with JEPs currently in Targeted or Proposed to Target state. Currently, this consists of the following features:
- 286: Local-Variable Type Inference
- 296: Consolidate the JDK Forest into a Single Repository
- 304: Garbage-Collector Interface
- 307: Parallel Full GC for G1
- 310: Application Class-Data Sharing
- 312: Thread-Local Handshakes
Of these, JEP 296 is purely housekeeping and JEP 304 increases code isolation of different garbage collectors and introduces a clean interface for garbage collectors.
The latter means that 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.
The change that is likely to provoke the most interest is JEP 286, which will allow the developer to reduce boilerplate in local variable declarations by enhancing type inference. This means that the following becomes legal Java as of the next release:
var list = new ArrayList<String>(); // infers ArrayList<String> var stream = list.stream(); // infers Stream<String>
This syntax will be restricted to local variables with initializers and local variables in for loops.
It is purely syntactic sugar implemented in the source code compiler and has no semantic significance. Nevertheless, experience shows that this feature is likely to provoke lively debate among Java developers.
The remaining three changes all have some impact, albeit potentially small, on performance.
JEP 307 solves a problem with the G1 garbage collector - as of Java 9 the current implementation of the full GC for G1 uses a single threaded (serial) algorithm.
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.
JEP 310 extends a feature called Class-Data Sharing (CDS), which allows a JVM to record a set of classes and process them into a shared archive file. This archive can then be memory-mapped into the JVM process on the next run to reduce startup time. The file can also be shared across JVMs and this can reduce overall memory footprint when multiple JVMs are running on the same host.
This capability has existed since Java 5, but as of Java 9, CDS only allows the bootstrap class loader to load archived classes. The aim of JEP 310 is to extend this to allow the application and custom classloaders to make use of archive files. This feature actually already exists but is currently only available in Oracle JDK, not OpenJDK.
This JEP therefore essentially consists of moving the feature into the open repo from the private Oracle sources, as from Java 10 onwards, regular (non-LTS) releases will be of OpenJDK binaries. That Oracle is moving this feature to the open repos indicates that they have production customers who are using it, and so Oracle will now need to support them on an OpenJDK binary.
Finally, JEP 312 lays the groundwork for improved VM performance, by making it possible to execute a callback on application threads without performing a global VM safepoint. This would mean that the JVM could stop individual threads and not just all of them. Some of the small, low-level improvements that this will enable include:
- Reducing the impact of acquiring a stack trace sample (e.g. for profiling)
- Better stack trace sampling by reducing reliance on signals.
- Improving biased locking by only stopping individual threads for revoking biases.
- Removing some memory barriers from the JVM
Overall, it seems that Java 10 is unlikely to contain any major new features or performance improvements. This is perhaps to be expected - instead of vast change, it represents the first release in the new, more frequent and gradual release cycle.
