Keeping track: Three new JEPs targeted to JDK 11

What’s in JDK 11 so far

• 309: Dynamic Class-File Constants
• 318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector
• 321: HTTP Client (Standard)
• 323: Local-Variable Syntax for Lambda Parameters

JEP 309: Dynamic Class-File Constants

Summary: Extend the Java class-file format to support a new constant-pool form,CONSTANT_Dynamic. Loading a CONSTANT_Dynamic will delegate creation to a bootstrap method, just as linking an invokedynamic call site delegates linkage to a bootstrap method.

JEP 318: Epsilon: A No-Op Garbage Collector

Summary: 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 321: HTTP Client (Standard)

Summary: Standardize the incubated HTTP Client API introduced in JDK 9, via JEP 110, and updated in JDK 10.

JEP 323: Local-Variable Syntax for Lambda Parameters

Summary: Allow var to be used when declaring the formal parameters of implicitly typed lambda expressions.

What’s out 

• 320: Remove the Java EE and CORBA Modules

The Java EE and CORBA modules were deprecated in Java SE 9 with the declared intent to remove them in a future release. Therefore, they will be removed in Java 11.

Read more about the risks of removing the  Java EE modules here. As far as CORBA is concerned, there won’t be a standalone version unless third parties take over maintenance of the CORBA APIs, ORB implementation, CosNaming provider, etc.

What’s new in JDK 11

JEP 324: Key Agreement with Curve25519 and Curve448

Cryptography using Curve25519 and Curve448 is in demand due to their security and performance properties. Key exchange using these curves is already supported in many other crypto libraries such as OpenSSL, BoringSSL, and BouncyCastle. This key exchange mechanism is an optional component of TLS 1.3, and is enabled in earlier TLS versions through commonly-used extensions.

This JEP is aimed to implement key agreement using Curve25519 and Curve448 as described in RFC 7748. However, keep in mind that RFC 7748 will only be implemented in the SunEC provider.

Read more about this JEP here.

 JEP 327: Unicode 10

Since Unicode is “an evolving industry standard, we must keep Java to date with the latest version.” This JEP aims to upgrade existing platform APIs to support version 10.0 of the Unicode Standard.

The goal of JEP 327 is to support the latest version of Unicode, mainly in the following classes:

• Character and String in the java.lang package,
• NumericShaper in the java.awt.font package, and
• Bidi, BreakIterator, and Normalizer in the java.text package.

The following Unicode specifications will not be implemented by this JEP:

• UTS #10, Unicode Collation Algorithm
• UTS #39, Unicode Security Mechanisms
• UTS #46, Unicode IDNA Compatibility Processing
• UTS #51, Unicode Emoji

SEE ALSO: JavaFX as a separate module: A look back and a leap forward

JavaFX as a separate module

Speaking of JDK 11, it should be noted that starting with the next release, JavaFX will be available as a separate module, decoupled from the JDK.

Oracle wrote in a white paper that JavaFX new fixes will continue to be supported on Java SE 8 through March 2022 and announced that they are “working with interested third parties to make it easier to build and maintain JavaFX as a separately distributable open-source module.”

If you want to read more about the decision to decouple JavaFX from the JDK, check out this article by Johan Vos in which he weighs in on the news and explains why it makes perfect sense to move the development of JavaFX to an open system.