Java 11: Public Review Specification(new features you can expect)

JDK 11, is just around the corner. Due in September 2018 as part of Oracle’s new six-month release cadence for the standard edition of Java, Version 11 has more than a half dozen announced features so far.

Java 11 is also set to lose some capabilities through the removal of CORBA and Java EE (recently renamed Jakarta EE) modules, as well as the removal of JavaFX..

Following are few features which are going to be in java 11:

• 309: Dynamic Class-File Constants
• 318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector
• 323: Local-Variable Syntax for Lambda Parameters

JEP 309: Dynamic Class-File Constants

JEP 309 ("Dynamic Class-File Constants") "seek[s] to reduce the cost and disruption of creating new forms of materializable class-file constants, which in turn offers language designers and compiler implementors broader options for expressivity and performance." JDK bug JDK-8189199 ("Minimal ConstantDynamic support") "implement[s] JEP 309 by properly parsing and resolving new CONSTANT_Dynamic constants in JVM class files used by Hotspot" and was resolved four days ago. JEP 309 was officially targeted for JDK 11 on 14 December 2017.

JEP 318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector

The currently stated goal of JEP 318 ("Epsilon: An Arbitrarily Low-Overhead Garbage Collector") is to "provide a completely passive GC implementation with a bounded allocation limit and the lowest latency overhead possible, at the expense of memory footprint and memory throughput." The JEP's summary currently states, "Develop a GC that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down." JEP 318 is associated with issue JDK-8174901 ("JEP 318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector") and was officially targeted for JDK 11 on 18 January 2018. Additional details regarding JEP 318 can be found in online resources such as The Last Frontier in Java Performance: Remove the Garbage Collector and Java garbage collector proposal aimed at performance testing.

JEP 320: Remove the Java EE and CORBA Modules

JEP 320 ("Remove the Java EE and CORBA Modules") has a current "Summary" stating, "Remove the Java EE and CORBA modules from the Java SE Platform and the JDK. These modules were deprecated in Java SE 9with the declared intent to remove them in a future release." This JEP is not terribly surprising given that CORBA and Java EE modules did not have default visibility in Java SE when JDK 9 introduced modularity. The "Motivation" section of this JEP provides insightful historical background on why Java EE and CORBA modules were included in Java SE in the first place. Among many other interesting tidbits in this "Motivation" section, these two conclusions stand out to me:

• "Since standalone versions of the Java EE technologies are readily available from third-party sites, such as Maven Central, there is no need for the Java SE Platform or the JDK to include them."
• "Since the costs of maintaining CORBA support outweigh the benefits, there is no case for the Java SE Platform or the JDK to include it."

JEP 320 lists several modules and tools that it will remove. The to-be-removed modules include java.xml.ws, java.xml.ws.annotation, jdk.xml.ws, java.xml.bind, jdk.xml.bind. The to-be-removed tools include wsgen, wsimport, schemagen, xjc, and servertool.

The JEP 320 "Risks and Assumptions" section illustrates the impact of these removals. It states that developers using --add-modules java.xml.bind currently to include JAXB classes in their Java 9 applications will need to change this for JDK 11. Specifically, the JEP text states, "This proposal assumes that developers who wish to compile or run applications on the latest JDK can find and deploy alternate versions of the Java EE technologies." Fortunately, the text in JEP 320 does a nice job of providing details on current alternate implementations of many of the libraries and tools that will be removed with JDK 11 and JEP 320.

JEP 320 also mentions that most modules it will be removing are "upgradeable," meaning that "developers on JDK 9 who use --add-modules java.xml.bind, etc. have the choice of either relying on the Java EE modules in the JDK runtime image, or overriding them by deploying API JAR files on the upgrade module path." The JEP further explains why this is significant in terms of making it easier to move to JDK 11 when the modules are removed from the JDK runtime image.

JEP 320 is associated with issue JDK-8189188 ("JEP 320: Remove the Java EE and CORBA Modules") and was officially targeted for JDK 11 on 26 January 2018.

JEP 323: Local-Variable Syntax for Lambda Parameters

JEP 323 ("Local-Variable Syntax for Lambda Parameters") is intended to "allow var to be used when declaring the formal parameters of implicitly typed lambda expressions."

So what do you guys think about these features. Let me know in comments.