BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JDK 23 and JDK 24: What We Know So Far

JDK 23 and JDK 24: What We Know So Far

JDK 23, the second non-LTS release since JDK 21, has reached its second 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 2024 (Rampdown Phase One), defines the feature set for JDK 23. 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 23 will be formally released on September 17, 2024.

The final set of 12 new features, in the form of JEPs, can be separated into four (4) categories: Core Java Library, Java Language Specification, HotSpot and Java Tools.

Six (6) of these new features are categorized under Core Java Library:

Four (4) of these new features are categorized under Java Language Specification:

One (1) of these new features are categorized under HotSpot:

And finally, one (1) of these new features is categorized under Java Tools:

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 482, Flexible Constructor Bodies (Second Preview), proposes a second round of preview and a name change to obtain feedback from the previous round of preview, namely JEP 447, Statements before super(...) (Preview), delivered in JDK 22. This feature allows 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. Changes in this JEP include: a treatment of local classes; and a relaxation of the restriction that fields can not be accessed before an explicit constructor invocation to a requirement that fields can not be read before an explicit constructor invocation. 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 477, Implicitly Declared Classes and Instance Main Methods (Third Preview), formerly known as Unnamed Classes and Instance Main Methods (Preview), Flexible Main Methods and Anonymous Main Classes (Preview) and Implicit Classes and Enhanced Main Methods (Preview), incorporates enhancements in response to feedback from the two previous rounds of preview, namely JEP 463, Implicit Classes and Instance Main Methods (Second Preview), to be delivered in the upcoming release of JDK 22, and JEP 445, Unnamed Classes and Instance Main Methods (Preview), delivered in JDK 21. This JEP 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. The latest draft of the specification document by Gavin Bierman, consulting member of technical staff at Oracle, is open for review by the Java community. More details on JEP 445 may be found in this InfoQ news story.

JEP 476, Module Import Declarations (Preview), proposes to enhance the Java programming language with the ability to succinctly import all of the packages exported by a module with a goal to simplify the reuse of modular libraries without requiring to import code to be in a module itself.

JEP 455, Primitive Types in Patterns, instanceof, and switch (Preview), proposes to enhance pattern matching by allowing primitive type patterns in all pattern contexts, and extend instanceof and switch to work with all primitive types. Aggelos Biboudis, principal member of technical staff at Oracle, has recently published an updated draft specification for this feature.

Project Loom

JEP 481, Scoped Values (Third Preview), formerly known as Extent-Local Variables (Incubator), proposes a third preview, with one change, in order to gain additional experience and feedback from one round of incubation and two rounds of preview, namely: JEP 464, Scoped Values (Second Preview), delivered in JDK 22; JEP 446, Scoped Values (Preview), delivered in JDK 21; and JEP 429, Scoped Values (Incubator), delivered in JDK 20. This feature enables sharing of immutable data within and across threads. This is preferred to thread-local variables, especially when using large numbers of virtual threads. The change in this feature is related to the operation parameter of the callWhere() method, defined in the ScopedValue class, is now a functional interface which allows the Java compiler to infer whether a checked exception might be thrown. With this change, the getWhere() method is no longer needed and has been removed.

JEP 480, Structured Concurrency (Third Preview), proposes a third preview, without change, in order to gain more feedback from the previous two rounds of preview, namely: JEP 462, Structured Concurrency (Second Preview), delivered in JDK 22; and JEP 453, Structured Concurrency (Preview), delivered in JDK 21. This feature simplifies concurrent programming by introducing structured concurrency to “treat groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.”

Project Panama

JEP 469, Vector API (Eighth Incubator), incorporates enhancements in response to feedback from the previous seven rounds of incubation: JEP 460, Vector API (Seventh Incubator), delivered in JDK 22; JEP 448, Vector API (Sixth Incubator), delivered in JDK 21; 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. Originally slated to be a re-incubation by reusing the original Incubator status, it was decided to keep enumerating. The Vector API will continue to incubate until the necessary features of Project Valhalla become available as preview features. At that time, the Vector API team will adapt the Vector API and its implementation to use them, and will promote the Vector API from Incubation to Preview.

An Update on String Templates

After two preview releases in JDK 21 and JDK 22, JEP 465, String Templates (Third Preview), was closed and withdrawn due to a number of unforeseen issues.. This feature had proposed 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 the reasoning on why this JEP was withdrawn may be found in this blog post by Nicolai Parlog, Java Developer Advocate at Oracle, and this email from Brian Goetz, Java Language Architect at Oracle.

JDK 24

Scheduled for a GA release in March 2025, there is only one JEP targeted for JDK 24 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 24.

JEP 472, Prepare to Restrict the Use of JNI, has been targeted for JDK 24. The JEP 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, delivered in JDK 22. The alignment strategy, starting in the upcoming release of JDK 23, 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 23, using JNI will throw exceptions instead of warnings. More details may be found in this InfoQ news story.

JEP 404, Generational Shenandoah (Experimental), has recently been updated to be included in JDK 24 despite its current Candidate status. We anticipate that this JEP will soon be promoted to Proposed to Target. Originally targeted for JDK 21, JEP 404 was officially removed from the final feature set 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 decided to "deliver the best Generational Shenandoah that they can” and target a future release.

JEP 401, Value Classes and Objects (Preview), formerly known as Null-Restricted Value Object Storage (Preview) and 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 8334712, Class-File API, proposes to finalize this feature in JDK 24 after two rounds of preview: JEP 466, Class-File API (Second Preview), to be delivered in the upcoming release of JDK 23; and JEP 457, Class-File API (Preview), delivered in JDK 22. This feature provides an API for parsing, generating, and transforming Java class files. This 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. Goetz has characterized ASM as "an old codebase with plenty of legacy baggage" and provided background information on how this feature will evolve and ultimately replace ASM.

JEP Draft 8326035, CDS Object Streaming, proposes to add an object archiving mechanism for Class-Data Sharing (CDS) in the Z Garbage Collector (ZGC) with a unified CDS object archiving format and loader. This feature will keep GC implementation details and policies separate from the CDS archived object streaming mechanism.

JEP Draft 8300911, PEM API (Preview), introduces an easy and intuitive API for encoding and decoding the Privacy-Enhanced Mail (PEM) format to describe value holders that can change, at most, once. This PEM format will be used for storing and sending cryptographic keys and certificates.

JEP Draft 8291976, Support HTTP/3 in the HttpClient, proposes to update JEP 321, HTTP Client, delivered in JDK 11, to support the HTTP/3 protocol. This will allow applications and libraries to interact with HTTP/3 servers and get the benefits of HTTP/3 with minimal code changes.

JEP Draft 8312611, Stable Values (Preview), formerly known as Computed Constants (Preview), 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.

We anticipate that Oracle will start targeting additional JEPs for JDK 24 very soon.

About the Author

Rate this Article

Adoption
Style

BT