Epsilon Garbage Collector

According to the JDK Enhancement Proposal (or JEP) 318, Epsilon is a low-overhead garbage collector (GC) whose purpose is to handle memory allocation without implementing any actual memory reclamation mechanism.

The goal 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,” state Java core developers in the proposal. “A successful implementation is an isolated code change, does not touch other GCs, and makes minimal changes in the rest of JVM.”

Even though Java already offers a broad choice of highly configurable GC implementations, the developers believe that it’s easier to maintain a separate GC implementation to address specific use cases, such as performance testing, memory pressure testing, VM interface testing, extremely short-lived jobs, last-drop latency improvements, or last-drop throughput improvements, than piling on another configuration option on the existing GC implementation.

Local-Variable Syntax for Lambda Parameters

Java 10 introduced Local Variable Type Inference to reduce the verbosity associated with writing Java code, and Java 11 expands it to allow var to be used when declaring the formal parameters of implicitly typed lambda expressions, as stated in JEP 323, titled Local-Variable Syntax for Lambda Parameters.

As such, instead of writing:

It will be possible to simply write:

The uniformity itself isn’t the only benefit of local-variable syntax for lambda parameters. Another benefit is that it will become possible to apply modifiers to local variables and lambda formals without losing brevity.

Dynamic Class-File Constants

The JEP 309 extends the Java class-file format to support a new constant-pool form, CONSTANT_Dynamic, in order to reduce the cost and disruption of creating new forms of materializable class-file constants. Just as linking an invokedynamic call site delegates linkage to a bootstrap method, so will loading a CONSTANT_Dynamic delegate creation to a bootstrap method.

According to Java core developers, the new constant-pool form will offer language designers and compiler implementors broader options for expressivity and performance. “Richer, more flexible, more highly-typed constants remove friction from the development of invokedynamic protocols, which in turn facilitates the movement of complex logic from run time to linkage time, improving program performance and simplifying compiler logic.”

What Won’t Make It to Java 11

Despite the above-described features, Java 11 will actually be leaner than Java 10 because it’s set to lose CORBA (Common Object Request Broker Architecture), Java EE modules, and JavaFX, a set of graphics and media packages that enables developers to design, create, test, debug, and deploy rich client applications.

CORBA is the open standard for heterogeneous computing, and it was deprecated, along with Java EE modules, in Java SE 9. Standalone versions of Java EE modules will still be available from third-party sites, but Oracle won’t any longer have to maintain two separate implementations: one in Java SE and the other one in Java EE.