With java 10 shipped on time, Oracle seems to be putting efforts into respecting the new 6 months release cycle schedule, to speed up java releases. This post summarizes some details about each of the four JEPs currently targeted for JDK 11 at the time of this writing.
JEP 309: Dynamic Class-File Constants
class-file format will be extended to support a new constant pool form,
CONSTANT_Dynamic. The goal of this JEP is to reduce the cost and disruption of developing new forms of materializable
class-file constraints, by creating a single new constant-pool form that can be parameterized with user-provided behavior.
JEP 318: Epsilon. An Arbitrarily Low-Overhead Garbage Collector
This JEP is billed as “A No-Op Garbage Collector”, and its purpose is to develop a garbage collector that handles memory allocation, without implementing any actual memory reclamation mechanism.
Epsilon’s use cases include testing for performance, memory pressure, and the virtual machine interface. It also could be used for short-lived jobs.
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
The Java EE and CORBA modules were deprecated in Java 9, with the intent to remove them in a later release, that is now set to be JDK 11.
JEP 320 lists several modules and tools that it will remove. The to-be-removed modules include
java.corba. The to-be-removed tools include wsgen, wsimport, schemagen, xjc, and servertool.
JEP 323: Local-Variable Syntax for Lambda Parameters
This JEP allows
var to be used when declaring the formal parameters of implicitly typed lambda expressions. The goal here is to align the syntax of a local variable declaration with the syntax of a formal parameter declaration in an implicitly typed lambda expression.
This means instead of writhing this:
(var x, var y) -> x.process(y)
We’ll be able to simply write:
(x, y) -> x.process(y)
This expands JEP 286, that introduced a new syntax that reduces the verbosity associated with writing Java, while maintaining the commitment to static type safety.
JavaFX decoupled from the JDK.
Speaking of JDK 11 and what’s not going to be included, it should be noted that starting with the next release, JavaFX will be available as a separate module and not tied to Java JDK’s twice-annual update schedule.