As declared by Iris Clark, JDK 23 is now in the crucial Rampdown Phase One, a significant milestone in the JDK development process. This phase started on Thursday, June 6, and the Java community eagerly anticipates the new features and enhancements that will be part of this release. This crucial phase marks the transition of changes intended for JDK 23 into the mainline repository, with the deadline set for 16:00 UTC on the same day. At the same time, the main line will branch into the JDK 23 stabilization branch, referred to as jdk23, ensuring a stable foundation for the upcoming builds. This phase involves integrating most changes via backports, mirroring the approach taken with JDK 22. 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:
- 466: Class-File API (Second Preview)
- 469: Vector API (Eighth Incubator)
- 473: Stream Gatherers (Second Preview)
- 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal
- 480: Structured Concurrency (Third Preview)
- 481: Scoped Values (Third Preview)
Four (4) of these new features are categorized under Java Language Specification:
- 455: Primitive Types in Patterns, instanceof, and switch (Preview)
- 476: Module Import Declarations (Preview)
- 477: Implicitly Declared Classes and Instance Main Methods (Third Preview)
- 482: Flexible Constructor Bodies (Second Preview)
One (1) of these new features are categorized under HotSpot:
And finally, one (1) of these new features is categorized under Java Tools:
JEP 466, Class-File API (Second Preview), proposes a second preview to obtain feedback from the previous round, and JEP 457, Class-File API (Preview), to be delivered in JDK 22. This JEP isn't about making class files faster or smaller. Instead, it provides a standardized way for tools to read, write, and modify class files. This means tools like debuggers, profilers, and code generators don't need to rely on custom, often fragile solutions. This will initially serve as an internal replacement for ASM, the Java bytecode manipulation and analysis framework, in the JDK, with plans to open it as a public API. Goetz has 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 469, Vector API (Eighth Incubator) incorporates enhancements in response to feedback from the previous six rounds of incubation: JEP 460, Vector API (Seventh Incubator), delivered in JDK 22, 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. Modern CPUs have instructions to perform single operations on multiple data elements simultaneously (SIMD). The Vector API gives Java developers access to this power. While it won't magically speed up every part of the code, it can drastically improve performance in compute-intensive tasks that can be parallelized at the data level, such as linear algebra, image processing, and machine learning.
JEP 473, Stream Gatherers (Second Preview), proposes a second preview round from the previous round, namely JEP 461, Stream Gatherers (Preview), delivered in JDK 22. This will allow additional time for feedback and more experience with this feature, with no user-facing changes over JEP 461. This feature was designed to enhance the Stream API to support custom intermediate operations that will “allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations.” Think of them as a way to bridge the gap between the high-level abstraction of streams and the specific needs of your data processing pipeline. More details on this JEP may be found in the original design document and this InfoQ news story.
JEP 471, Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal deprecates the memory access methods in the Unsafe class for removal in a future release. Standard APIs have superseded these unsupported methods: JEP 193, Variable Handles, delivered in JDK 9; and JEP 454, Foreign Function & Memory API, delivered in JDK 22. This JEP is a big step towards enhancing Java's security and portability. The sun.misc.Unsafe class, while powerful, provides unchecked access to memory, which can lead to crashes and security vulnerabilities. By deprecating specific methods, Java is nudging developers towards safer and more maintainable practices.
JEP 480, Structured Concurrency (Third Preview), offers 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."
JEP 481, Scoped Values (Third Preview), formerly known as Extent-Local Variables (Incubator), this JEP offers 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 the 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, which 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. This can lead to cleaner code and improved performance in scenarios where frequent data sharing is required.
JEP 455, Primitive Types in Patterns, Instanceof, and Switch (Preview), under the auspices of Project Amber, enhances pattern matching by allowing primitive type patterns in all pattern contexts and extending instanceof and switch to work with all primitive types. Pattern matching is a powerful tool for expressing complex conditional logic. This JEP extends its reach to primitive types, allowing you to write more concise and readable code when dealing with basic data types like numbers and booleans. More details on this JEP may be found in this InfoQ news story.
JEP 476, Module Import Declarations (Preview), enhances the Java programming language by allowing users to import succinctly all of the packages exported by a module. The goal is to simplify the reuse of modular libraries without requiring code to be in the module itself. This JEP streamlines the importing of entire modules in Java, thus simplifying code and making it easier for developers, especially beginners, to utilize libraries and standard classes. This feature reduces the need for multiple import statements and eliminates the necessity of knowing the package hierarchy. More details on this JEP may be found in this InfoQ news story.
JEP 477, Implicitly Declared Classes and Instance Main Methods (Third Preview), offers to "evolve the Java language so that students can write their first programs without needing to understand language features designed for large programs." Sometimes, all you need is a small, single-file program. This JEP lets developers write such programs without the boilerplate of defining a class and the main method. It's a small but welcome improvement for scripting and prototyping and facilitates a beginner's gradual learning curve, allowing beginners to start with simple, concise code and progressively adopt more advanced features as they gain experience. This JEP moves forward the September 2022 blog post, Paving the on-ramp, by Brian Goetz, the Java language architect at Oracle. The latest draft of the specification document by Gavin Bierman, a consulting member of the technical staff at Oracle, is open for review by the Java community. More details on this JEP may be found in this InfoQ news story.
JEP 482, Flexible Constructor Bodies (Second Preview), offers 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. Constructors are the gateway to creating objects. This JEP relaxes some of the restrictions around constructor bodies, allowing you to perform tasks like validating arguments before assigning them to fields, leading to more robust and less error-prone code. 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, a consulting member of the technical staff at Oracle, has provided an initial specification of this JEP for the Java community to review and provide feedback.
JEP 474: ZGC: Generational Mode by Default proposes to use the Z Garbage Collector (ZGC) from non-generational to generational mode by default. The non-generational mode will be deprecated and removed in a future JDK release. This will ultimately reduce the cost of maintaining the two modes, so future development can primarily focus on JEP 439, Generational ZGC.
JEP 467, Markdown Documentation Comments, offers to enable JavaDoc documentation comments to be written in Markdown rather than a mix of HTML and JavaDoc @ tags. Developers love Markdown for its readability and ease of use. This JEP brings that love to Java documentation and allows for documentation comments that are easier to write and read in source form. More details on this JEP may be found in this InfoQ news story.
As JDK 23 progresses through its development milestones, developers can expect a range of improvements and new functionalities that enhance performance, security, and productivity. The integration of these JEPs showcases the ongoing commitment to making Java more powerful and developer-friendly. Developers can refer to the OpenJDK mailing list, JDK mainline repository and the JDK 23 schedule to stay updated.