JDK 20 and JDK 21: What We Know So Far

MMS Founder
MMS Michael Redlich

Article originally posted on InfoQ. Visit InfoQ

JDK 20, the third non-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 mid-December 2022 (Rampdown Phase One), defines the feature set for JDK 20. 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 20 will be formally released on March 21, 2023. It is worth noting that JEP 438 was added to the feature set in early March 2023.

The final set of seven (7) new features, in the form of JEPs, can be separated into two (2) categories: Core Java Library and Java Specification.

Five (5) of these new features are categorized under the Core Java Library:

Two (2) of these new features are categorized under the Java Specification:

We examine 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 432, Record Patterns (Second Preview), incorporates enhancements in response to feedback from the previous round of preview, JEP 405, Record Patterns (Preview). This proposes to enhance 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 406, Pattern Matching for switch (Preview), delivered in JDK 17; and JEP 420, Pattern Matching for switch (Second Preview), delivered in JDK 18. Changes from JEP 405 include: added support for inference of type arguments of generic record patterns; added support for record patterns to appear in the header of an enhanced for statement; and remove support for named record patterns.

Similarly, JEP 433, Pattern Matching for switch (Fourth Preview), incorporates enhancements in response to feedback from the previous three rounds of preview: JEP 427, Pattern Matching for switch (Third Preview), delivered in JDK 19; JEP 420, Pattern Matching for switch (Second Preview), delivered in JDK 18; and JEP 406, Pattern Matching for switch (Preview), delivered in JDK 17. Changes from JEP 427 include: a simplified grammar for switch labels; and inference of type arguments for generic type patterns and record patterns is now supported in switch expressions and statements along with the other constructs that support patterns.

Project Loom

JEP 429, Scoped Values (Incubator), an incubating JEP formerly known as Extent-Local Variables (Incubator), 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 436, Virtual Threads (Second Preview), proposes a second preview from JEP 425, Virtual Threads (Preview), delivered in JDK 19, to allow time for additional feedback and experience for this feature to progress. 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. It is important to note that no changes are within this preview except for a small number of APIs from JEP 425 that were made permanent in JDK 19 and, therefore, not proposed in this second preview. More details on JEP 425 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.

JEP 437, Structured Concurrency (Second Incubator), proposes to reincubate this feature from JEP 428, Structured Concurrency (Incubator), delivered in JDK 19, to allow time for additional feedback and experience. The intent of this feature is to simplify multithreaded programming by introducing a library to treat multiple tasks running in different threads as a single unit of work. This can streamline error handling and cancellation, improve reliability, and enhance observability. The only change is an updated StructuredTaskScope class to support the inheritance of scoped values by threads created in a task scope. This streamlines the sharing of immutable data across threads. More details on JEP 428 may be found in this InfoQ news story.

Project Panama

JEP 434, Foreign Function & Memory API (Second Preview), incorporate refinements based on feedback and to provide a second preview from 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 424 include: the MemorySegment and MemoryAddress interfaces are now unified, i.e., memory addresses are modeled by zero-length memory segments; and the sealed MemoryLayout interface has been enhanced to facilitate usage with JEP 427, Pattern Matching for switch (Third Preview), delivered in JDK 19.

JEP 438, Vector API (Fifth Incubator), incorporates enhancements in response to feedback from the previous four rounds of incubation: 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 JEP 424, Foreign Function & Memory API (Preview).

JDK 21

Scheduled for a GA and next LTS release in September 2023, two (2) JEPs are currently Proposed to Target for JDK 21.

JEP 430, String Templates (Preview), a feature JEP type, proposes to enhance the Java programming language with string templates, which are similar to string literals but which contain embedded expressions that are incorporated into the string template at run time. This feature has been classified as Proposed to Target for JDK 21, but has not yet been formally announced with a review date.

JEP 431, Sequenced Collections, proposes to introduce “a new family of interfaces that represent the concept of a collection whose elements are arranged in a well-defined sequence or ordering, as a structural property of the collection.” This is motivated by the lack of a well-defined ordering and uniform set of operations within the Collections Framework. This feature has been classified as Proposed to Target for JDK 21, but has not yet been formally announced with a review date.

We can surmise which additional JEPs have the potential to be included in JDK 21 based on a number of JEP drafts and candidates.

JEP Draft 8303358, Scoped Values (Preview), submitted by Andrew Haley and Andrew Dinn, both distinguished engineers at Red Hat, evolves JEP 429, Scoped Values (Incubator), delivered in the upcoming release of JDK 20. Formerly known as Extent-Local Variables (Incubator) and under the auspices of Project Loom, this feature 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. And while this draft has not yet reached Candidate status, the description explicitly states that this JEP will be added in JDK 21.

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 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, Primitive Classes (Preview), under the auspices of Project Valhalla, introduces developer-declared primitive classes – special kinds of value classes – as defined in the aforementioned Value Objects (Preview) JEP Draft – that define new primitive types.

JEP Draft 8301034, Key Encapsulation Mechanism API, a feature JEP type, proposes to: satisfy implementations of standard Key Encapsulation Mechanism (KEM) algorithms; satisfy use cases of KEM by higher level security protocols; and allow service providers to plug-in Java or native implementations of KEM algorithms. This draft was recently updated to include a major change that eliminates the DerivedKeyParameterSpec class in favor of placing fields in the argument list of the encapsulate(int from, int to, String algorithm) method.

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 additional JEPs for JDK 21 very soon.

About the Author

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.