The list is getting longer

Keeping track: Three new JEPs targeted to JDK 11

May 15, 2018 Gabriela Motroc

#java #jdk11

May is shaping up to be a busy month for JDK 11 now that three more JEPs are targeted to the next Java version. In this article, we’re going to have a look at each new JEP and make a quick summary of what’s targeted to JDK 11 so far.

The countdown to JDK 11 has begun -sort of- and the list of JEPs is getting longer.

Last week, Mark Reinhold announced three new JEPs to target JDK 11 [ in three messages on the jdk-dev mailing list]:

This means there are currently eight JEPs targeted to the next Java version.

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

Read more about this JEP here.

JEP 328: Flight Recorder

Troubleshooting, monitoring and profiling are integral parts of the development lifecycle, but some problems occur only in production, under heavy load involving real data.

Flight Recorder records events originating from applications, the JVM and the OS. Events are stored in a single file that can be attached to bug reports and examined by support engineers, allowing after-the-fact analysis of issues in the period leading up to a problem. Tools can use an API to extract information from recording files.

This JEP aims to provide a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM. Its goals are to:

Provide APIs for producing and consuming data as events
Provide a buffer mechanism and a binary data format
Allow the configuration and filtering of events
Provide events for the OS, the HotSpot JVM, and the JDK libraries

Read more about this JEP here.

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.

Author

Gabriela Motroc

@GabrielaMotroc

All Posts by Gabriela Motroc

Gabriela Motroc is editor of JAXenter.com and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.