JDK 21, the next Long-Term Support (LTS) release since JDK 17, has reached its initial release candidate phase as declared by Mark Reinhold, chief architect, Java Platform Group at Oracle. The main-line source repository, forked to the JDK stabilization repository in early-June 2023 (Rampdown Phase One), defines the feature set for JDK 21. Critical bugs, such as regressions or serious functionality issues, may be addressed, but must be approved via the Fix-Request process. As per the release schedule, JDK 21 will be formally released on September 19, 2023.
The final set of 15 new features, in the form of JEPs, can be separated into four (4) categories: Core Java Library, Java Language Specification, HotSpot and Security Library.
Six (6) of these new features are categorized under Core Java Library:
- JEP 431: Sequenced Collections
- JEP 442: Foreign Function & Memory API (Third Preview)
- JEP 444: Virtual Threads
- JEP 446: Scoped Values (Preview)
- JEP 448: Vector API (Sixth Incubator)
- JEP 453: Structured Concurrency (Preview)
Five (5) of these new features are categorized under Java Language Specification:
- JEP 430: String Templates (Preview)
- JEP 440: Record Patterns
- JEP 441: Pattern Matching for switch
- JEP 443: Unnamed Patterns and Variables (Preview)
- JEP 445: Unnamed Classes and Instance Main Methods (Preview)
Three (3) of these new features are categorized under HotSpot:
- JEP 439: Generational ZGC
- JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
- JEP 451: Prepare to Disallow the Dynamic Loading of Agents
And finally, one (1) of these new features is categorized under Security Library:
- JEP 452: Key Encapsulation Mechanism API
It is important to note that JEP 404, Generational Shenandoah (Experimental), originally targeted for JDK 21, was officially removed from the final feature set in JDK 21. This was due to the "risks identified during the review process and the lack of time available to perform the thorough review that such a large contribution of code requires." The Shenandoah team has decided to "deliver the best Generational Shenandoah that they can" and will seek to target JDK 22.
We examine some of these new features and include where they fall under the auspices of the four major Java projects - Amber, Loom, Panama and Valhalla - designed to incubate a series of components for eventual inclusion in the JDK through a curated merge.
Project Amber
JEP 445, Unnamed Classes and Instance Main Methods (Preview), formerly known as Flexible Main Methods and Anonymous Main Classes (Preview) and Implicit Classes and Enhanced Main Methods (Preview), proposes to "evolve the Java language so that students can write their first programs without needing to understand language features designed for large programs." This JEP moves forward the September 2022 blog post, Paving the on-ramp, by Brian Goetz, Java language architect at Oracle. Gavin Bierman, consulting member of technical staff at Oracle, has published the first draft of the specification document for review by the Java community. More details on JEP 445 may be found in this InfoQ news story.
JEP 440, Record Patterns, finalizes this feature and incorporates enhancements in response to feedback from the previous two rounds of preview: JEP 432, Record Patterns (Second Preview), delivered in JDK 20; and JEP 405, Record Patterns (Preview), delivered in JDK 19. This feature enhances the language with record patterns to deconstruct record values. Record patterns may be used in conjunction with type patterns to "enable a powerful, declarative, and composable form of data navigation and processing." Type patterns were recently extended for use in switch case labels via: JEP 420, Pattern Matching for switch (Second Preview), delivered in JDK 18, and JEP 406, Pattern Matching for switch (Preview), delivered in JDK 17. The most significant change from JEP 432 removed support for record patterns appearing in the header of an enhanced for statement. Further details on JEP 440 may be found in this InfoQ news story.
JEP 430, String Templates (Preview), proposes to enhance the Java programming language with string templates, string literals containing embedded expressions, that are interpreted at runtime where the embedded expressions are evaluated and verified. More details on JEP 430 may be found in this InfoQ news story.
Project Loom
JEP 453, Structured Concurrency (Preview), incorporates enhancements in response to feedback from the previous two rounds of incubation: JEP 428, Structured Concurrency (Incubator), delivered in JDK 19; and JEP 437, Structured Concurrency (Second Incubator), delivered in JDK 20. Recent significant changes include: the TaskHandle interface has been renamed to Subtask a fix to correct the generic signature of the handleComplete() method; a change to the states and behavior of subtasks on cancellation; a new currentThreadEnclosingScopes() method defined in the Threads class that returns a string with the description of the current structured context; and the fork() method, defined in the StructuredTaskScope class, returns an instance of Subtask (formerly known as TaskHandle) rather than a Future since the get() method in the old TaskHandle interface was restructured to behave the same as the resultNow() method in the Future interface. Further details on JEP 453 may be found in this InfoQ news story.
JEP 446, Scoped Values (Preview), formerly known as Extent-Local Variables (Incubator), is now a preview feature following JEP 429, Scoped Values (Incubator), delivered in JDK 20. This JEP proposes to enable sharing of immutable data within and across threads. This is preferred to thread-local variables, especially when using large numbers of virtual threads.
JEP 444, Virtual Threads, proposes to finalize this feature based on feedback from the previous two rounds of preview: JEP 436, Virtual Threads (Second Preview), delivered in JDK 20; and JEP 425, Virtual Threads (Preview), delivered in JDK 19. This feature provides virtual threads, lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications, to the Java platform. The most significant change from JEP 436 is that virtual threads now fully support thread-local variables by eliminating the option to opt-out of using these variables. More details on JEP 444 may be found in this InfoQ news story and this JEP Café screen cast by José Paumard, Java developer advocate, Java Platform Group at Oracle.
Project Panama
JEP 448, Vector API (Sixth Incubator), incorporates enhancements in response to feedback from the previous five rounds of incubation: JEP 438, Vector API (Fifth Incubator), delivered in JDK 20; JEP 426, Vector API (Fourth Incubator), delivered in JDK 19; JEP 417, Vector API (Third Incubator), delivered in JDK 18; JEP 414, Vector API (Second Incubator), delivered in JDK 17; and JEP 338, Vector API (Incubator), delivered as an incubator module in JDK 16. This feature proposes to enhance the Vector API to load and store vectors to and from a MemorySegment as defined by the Foreign Function & Memory API.
JEP 442, Foreign Function & Memory API (Third Preview), incorporates refinements based on feedback and to provide a third preview from: JEP 434, Foreign Function & Memory API (Second Preview), delivered in JDK 20; JEP 424, Foreign Function & Memory API (Preview), delivered in JDK 19, and the related incubating JEP 419, Foreign Function & Memory API (Second Incubator), delivered in JDK 18; and JEP 412, Foreign Function & Memory API (Incubator), delivered in JDK 17. This feature provides an API for Java applications to interoperate with code and data outside of the Java runtime by efficiently invoking foreign functions and by safely accessing foreign memory that is not managed by the JVM. Updates from JEP 434 include: centralizing the management of the lifetimes of native segments in the Arena interface; enhanced layout paths with a new element to dereference address layouts; and removal of the VaList class.
Developers may be interested in learning about the performance benefits of the Foreign Function & Memory API that is planned to be a final feature in JDK 22. Per-Åke Minborg, consulting member of technical staff at Oracle, has published this blog post in which he provided a benchmark on string conversion using this API for JDK 21 (JEP 442) and JDK 22 (JEP Draft 8310626) compared to using the old Java Native Interface (JNI) calls.
HotSpot
JEP 439, Generational ZGC, proposes to "improve application performance by extending the Z Garbage Collector (ZGC) to maintain separate generations for young and old objects. This will allow ZGC to collect young objects, which tend to die young, more frequently." Further details on JEP 439 may be found in this InfoQ news story.
JDK 22
Scheduled for a GA release in March 2024, there are no targeted JEPs for JDK 22 at this time. However, based on a number of JEP candidates and drafts, especially those that have been submitted, we can surmise which additional JEPs have the potential to be included in JDK 22.
JEP 447, Statements before super(), under the auspices of Project Amber, proposes to: allow statements that do not reference an instance being created to appear before the this() or super() calls in a constructor; and preserve existing safety and initialization guarantees for constructors. Gavin Bierman, consulting member of technical staff at Oracle, has provided an initial specification of this JEP for the Java community to review and provide feedback.
JEP 435, Asynchronous Stack Trace VM API, a feature JEP type, proposes to define an efficient API for obtaining asynchronous call traces for profiling from a signal handler with information on Java and native frames.
JEP 401, Null-Restricted Value Object Storage (Preview), formerly known as Primitive Classes (Preview), under the auspices of Project Valhalla, introduces developer-declared primitive classes - special kinds of value classes as defined by the Value Objects API - that define new primitive types.
JEP Draft 8307341, Prepare to Restrict The Use of JNI, proposes to restrict the use of the inherently unsafe Java Native Interface (JNI) in conjunction with the use of restricted methods in the Foreign Function & Memory (FFM) API that is expected to become a final feature in JDK 22. The alignment strategy, starting in JDK 22, will have the Java runtime display warnings about the use of JNI unless an FFM user enables unsafe native access on the command line. It is anticipated that in release after JDK 22, using JNI will throw exceptions instead of warnings.
JEP Draft 8310626, Foreign Function & Memory API, proposes to finalize this feature after two rounds of incubation and three rounds of preview: JEP 412, Foreign Function & Memory API (Incubator), delivered in JDK 17; JEP 419, Foreign Function & Memory API (Second Incubator), delivered in JDK 18; JEP 424, Foreign Function & Memory API (Preview), delivered in JDK 19; JEP 434, Foreign Function & Memory API (Second Preview), delivered in JDK 20; and JEP 442, Foreign Function & Memory API (Third Preview), to be delivered in the upcoming release of JDK 21. Improvements since the last release include: a new Enable-Native-Access manifest attribute that allows code in executable JARs to call restricted methods without the use of the --enable-native-access flag; allow clients to programmatically build C function descriptors, avoiding platform-specific constants; improved support for variable-length arrays in native memory; and support for multiple charsets in native strings.
JEP Draft 8288476, Primitive types in patterns, instanceof, and switch (Preview), proposes to "enhance pattern matching by allowing primitive type patterns to be used in all pattern contexts, align the semantics of primitive type patterns with instanceof, and extend switch to allow primitive constants as case labels."
JEP Draft 8277163, Value Objects (Preview), a feature JEP under the auspices of Project Valhalla, proposes the creation of value objects - identity-free value classes that specify the behavior of their instances. This draft is related to JEP 401, Primitive Classes (Preview), which is still in Candidate status.
JEP Draft 8313278, Ahead of Time Compilation for the Java Virtual Machine, proposes to "enhance the Java Virtual Machine with the ability to load Java applications and libraries compiled to native code for faster startup and baseline execution."
JEP Draft 8312611, Computed Constants, introduces the concept of computed constants, defined as immutable value holders that are initialized at most once. This offers the performance and safety benefits of final fields, while offering greater flexibility as to the timing of initialization. This feature will debut as a preview API.
JEP Draft 8283227, JDK Source Structure, an informational JEP type, describes the overall layout and structure of the JDK source code and related files in the JDK repository. This JEP proposes to help developers adapt to the source code structure as described in JEP 201, Modular Source Code, delivered in JDK 9.
JEP Draft 8280389, ClassFile API, proposes to provide an API for parsing, generating, and transforming Java class files. This JEP will initially serve as an internal replacement for ASM, the Java bytecode manipulation and analysis framework, in the JDK with plans to have it opened as a public API. Brian Goetz, Java language architect at Oracle, characterized ASM as "an old codebase with plenty of legacy baggage" and provided background information on how this draft will evolve and ultimately replace ASM.
JEP Draft 8278252, JDK Packaging and Installation Guidelines, an informational JEP, proposed to provide guidelines for creating JDK installers on macOS, Linux and Windows to reduce the risks of collisions among JDK installations by different JDK providers. The intent is to promote a better experience when installing update releases of the JDK by formalizing installation directory names, package names, and other elements of installers that may lead to conflicts.
We anticipate that Oracle will start targeting JEPs for JDK 22 very soon.