With JDK 10 about to enter its release candidate phase, it’s interesting to start looking at what will come after that via JDK 11. As of this writing, four JEPs (JDK Enhancement Proposals) have been officially targeted for JDK 11 (with more likely to come). This post summarizes some details about each of the four JEPs currently targeted for JDK 11.
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 ofJEP 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 9 with 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.”
JEP 323 is associated with issue JDK-8193259 (“JEP 323: Local-Variable Syntax for Lambda Parameters”) and was officially targeted for JDK 11 yesterday (2 February 2018).
Conclusion
I mostly like to look forward to what’s coming soon to a JDK near me because I find it interesting to think about. However, there are also practical advantages in some cases to knowing what’s coming. For example, JEP 320 provides details regarding alternatives to the modules and tools that will be removed in JDK 11. Developers can start moving to those alternatives now or before migrating to JDK 11 to make that future transition easier.
| Published on Java Code Geeks with permission by Dustin Marx, partner at our JCG program. See the original article here: An Early Look at Features Targeted for Java 11 Opinions expressed by Java Code Geeks contributors are their own. |
