Keeping track: Three new JEPs targeted to JDK 11
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
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.
Serverless Deployments with Canary – Creating DevOps engineers at LEGO.com
Nicole Yip (The LEGO Group)
The Road to the Continuous Monitoring
Pawel Piwosz (Epam Systems)
Hacking Terraform for Fun and Profit
Anton Babenko (Betajob)
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:
CharacterandStringin thejava.langpackage,NumericShaperin thejava.awt.fontpackage, andBidi,BreakIterator, andNormalizerin thejava.textpackage.
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.
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.
Leave a Reply