Java 11 Features and Updates
Java 11 is scheduled for release in September 2018 with many additional features and four JDK enhancement proposals or JEPs have been officially targeted at Java 11 and the following versions. Java 10 sports JEP 296, which is for consolidating the JDK forest into a single repository, and JEP 304, which is a garbage collector interface. In other words, JEP 296 is meant for purely housekeeping and JEP 304 is meant for making the production of JDK builds that contains, or excludes a specific GC algorithm easier for vendors. Another Java Enhancement Process that has been in the loop since the release of Java 5 is the capability of sharing files across JVMs to reduce the overall memory footprint when multiple JVMs are running on the same host. But Java 10 extended this feature by introducing the JEP 310 to Oracle JDK, which allows the application and custom class loaders to make use of archive files.
Version JEP 309
The four JEPs lined up for Java 11 are quite different from all of these common ones in the past versions. JEP 309 is for Dynamic Class File Constants. To understand this, we must know about ‘bootstrapping’ or the ‘bootstrap method, which basically means that the code prepares everything necessary for executing a job later. This is linked to the 'invoke dynamic' opcode. Just like linking an invoke dynamic call site delegates linkage to a bootstrap method, loading the JEP 309 supported Constant_dynamic will delegate creation to the bootstrap method. Thus, JEP 309 essentially extends the Java class file format to reduce the cost and disruption of creating new configurations of materializable class file constants.
This offers a broader range of options for expressivity and performance to the language designers and compiler implementers. Thus, the Constant_Dynamic is a constant-pool form that is new to the community and it can be parameterized with user-provided behavior, particularly in the form of a bootstrap method with static arguments. Although there are a few alternatives to JEP 309, such as equivalent invoke dynamic calls and using static final fields to name the desired constants and making use of the static initializer to compute their values, the practical metadata overheads for stimulating these features are too large.
Version JEP 318
The next JEP in line is the JEP 318 Epsilon. This is meant for improving the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface. However, this is not meant to fully achieve build time isolation. This JEP will simply provide better modularity for Hotspot internal GC code and make it simpler to add a new GC to Hotspot without disturbing the current code base. Every garbage collector needs the existing class CollectedHeap in order to implement the defined GC interface. This CollectedHeap class would be driven by most aspects of the interaction between the garbage collector and the rest of Hotspot and that is why there are a few utility classes, which are needed before instantiation of the CollectedHeap class.
A helper class would contain the code for implementation details that are shared between multiple garbage collectors. This allows different GC implementations to use it easily. This is how the new interface provides flexibility to implement totally new barriers while allowing the reuse of existing code in a mix-and-match style. The only alternative to this is continuing to use the current architecture although that will certainly hinder the future development of new GC algorithms and removal of obsolete ones. In other words, this is purely a step towards advancement with minimal risks. Even so, the standard regression tests suites suffice for the JEP 318 as a refactoring of HotSpot internal code is the only risk to the performance. As continuous performance testing can mitigate this, the JEP 318 is expected to basically help with the older JEP 291 CMS Garbage Collector by isolating or maintaining it. The JEP 189: Shenandoah will also be affected, as the JEP 318 Epsilon will make its changes less intrusive.
Version JEP 320
The JEP 320 is for removing the Java EE and CORBA modules from the Java SE Platform and the JDK. They were already depreciated in an older version with the intention of removing them with future releases. There is no particular need for the Java SE Platform or the JDK to include the standalone versions of the Java EE technologies, as they are readily available from third-party sites, such as Maven Central. Plus, the costs of maintenance of the CORBA support outweigh its benefits since there is absolutely no interest in the development of modern applications with CORBA in Java. Removing all the JDK, JCK and SQE tests that exercise the APIs of Java EE and CORBA will make Java 11 much different from the previous versions.
JEP 323 is introduced with the goal of aligning the syntax of a formal parameter declaration in an implicitly typed lambda expression with the syntax of a local variable declaration. This simply means the use of ‘allow var’ during the declaration of formal parameters of implicitly typed lambda expressions.
How these JEPs fares with the users are yet to be seen.
Also, Read Core Java interview questions