Java Development Kit (JDK) 23, the next release of standard Java, has reached the release candidate stage. General availability is slated for September 17.
The feature set for JDK 23 has been finalized at an even dozen. A proposed third preview of string templates, which was previewed in JDK 22 and JDK 21, has been dropped from JDK 23.
JDK 23 will include third previews of scoped values, structured concurrency, and implicitly declared classes and instance methods, and second previews of flexible constructor bodies, stream gatherers, and a class-file API. JDK 23 will also include module import declarations, Markdown documentation comments, an eighth incubation of a vector API, and a preview of primitive types in patterns, instanceof, and switch. And the release will deprecate the memory access methods in sun.misc.UnSafe and make the generational mode of the Z Garbage collector the default mode.
JDK 23 will be a non-LTS (Long Term Support) release with only six months of support from Oracle, unlike JDK 21, which is an LTS release with several years of support. Early access builds for JDK 23 can be accessed from jdk.java.net.
Scoped values, previewed previously in JDK 22 and JDK 21, enable a method to share immutable data both with its callees within a thread and with child threads. Scoped values are easier to reason about than thread-local values and they have lower space and time costs, particularly when used together with virtual threads and structured concurrency, the proposal states. The preview of scoped values in JDK 23 introduces one change from the previous previews: The type of the operation parameter on the ScopedValue.callWhere method is a new functional interface that allows the Java compiler to infer whether a checked exception might be thrown. With this change, the ScopeValue.getWhere method is no longer needed and has been removed.
Plans for JDK 23 also call for deprecating the memory-access methods in sun.misc.Unsafe for removal in a future release. These methods are unsupported and they have been superseded by standard APIs, namely the VarHandle API and the foreign function and memory API. Library developers are encouraged to migrate from sun.misc.Unsafe to supported replacements, so applications can migrate smoothly to modern JDK releases. Goals of the proposal include preparing the ecosystem for removal of memory access methjods in sun.misc.Unsafe in a future JDK release, and helping developers realize when their applications rely, directly or indirectly, on those memory access methods. It is not a goal to remove sun.misc.Unsafe entirely, as a small number of its methods are not used for memory access. These methods will be deprecated and removed separately.
Structured concurrency would get a third preview in JDK 23, having been previewed in JDK 22 and JDK 21. Its purpose is to simplify concurrent programming by introducing an API for structured concurrency, which treats groups of related tasks in different threads as a single unit of work, streamlining error handling and cancellation to improve reliability and observability. The goals of this proposal include promoting a style of programming that can eliminate common risks arising from cancellation and shutdown, such as thread leaks and cancellation delays, and improving the observability of concurrent code.
Flexible constructor bodies would get a second preview in JDK 23. The feature was previewed in JDK 22 under the name of statements before super(…). This proposal would allow a constructor body to initialize fields in the same class before explicitly invoking a constructor. It is intended to give developers greater freedom to express the behavior of constructors, enabling more natural placement of logic that currently must be factored into auxiliary static methods, auxiliary intermediate constructors, or constructor arguments. The feature also is intended to preserve the guarantee that constructors run in a top-down order during class instantiation, ensuring that code in a subclass constructor cannot interfere with superclass instantiation.
Previously previewed in JDK 21 and JDK 22, implicitly declared classes and instance methods evolves the Java language to allow beginners to write their first programmers without needing to understand language features designed for large programs. Beginners can write streamlined declarations for single-class programs and then seamlessly expand programs to use more advanced features as their skills grow. Two enhancements are being added in JDK 23: Implicitly declared classes will import automatically three static methods for simple text I/O with the console, and will import on demand all public top-level classes and interfaces of packages exported by the java.base module.
Module import declarations, which would be a preview feature in JDK 23, enhance Java with the ability to succinctly import all packages exported by the module. This proposal, which was created in August, simplifies the reuse of modular libraries, but does not require the imported code to be in a module itself. Goals include simplifying the use of modular libraries by allowing entire modules to be imported at once and avoiding the noise of multiple type-import-on-demand declarations when using diverse parts of the API exported by a module. Another goal is allowing beginners to more easily use third-party libraries and fundamental Java classes without having to learn where they are located in a package hierarchy.
Markdown documentation comments, a proposal created last September, would enable JavaDoc documentation comments to be written in Markdown rather than solely in a mixture of HTML and JavaDoc @tags. The proposal is intended to make API documentation comments easier to write and read in source form by introducing the ability to use Markdown syntax alongside HTML elements and JavaDoc tags. It also is intended to extend the Compiler Tree API to enable other tools that analyze documentation comments to handle Markdown content. The plan should not adversely affect the interpretation of existing documentation comments.
JDK 23 is also slated to switch the default mode of the Z Garbage Collector (ZGC) to the generational mode. Generational ZGC is intended to boost Java application performance by more frequently collecting young objects, which tend to die young. The non-generational mode would be deprecated, with the intent to remove it in a future release. Goals of this feature include signaling the intent that future development will focus on generational ZGC, and reducing the maintenance cost of supporting the two different modes. Maintaining non-generational ZGC slows the development of new features. ZGC was added to Java in JDK 15 in September 2020.
The vector API, which has been incubated in previous Java versions from JDK 16 to last month’s JDK 22, introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPU architectures. Goals of the proposal include providing a clear and concise API, providing reliable runtime compilation and performance on x64 and AArch64 architectures, providing graceful degradation, being platform-agnostic, and aligning with Project Valhalla, which is intended to augment the Java object model with value objects.
Stream gatherers, previously previewed in JDK 22, would enhance the stream API to support custom intermediate operations. Stream gatherers would allow stream pipelines to transform data in ways not easily achievable with the existing built-in intermediate operations. Goals include making stream pipelines more flexible and expressive and allowing custom intermediate operations to manipulate streams of infinite size.
The class-file API is intended to provide an API for processing class files that tracks the class file format defined by the Java Virtual Machine specification. It also would enable JDK components to migrate to the standard API and eventually remove the JDK’s internal copy of the third-party ASM library. The class-file API would add refinements including streamlining the CodeBuilder class, which has factory methods for bytecode instructions, including low-level factories, mid-level factories, and high-level builders for basic blocks.
For JDK 23, Java’s builders removed mid-level methods that duplicated low-level methods or were infrequently used, while renaming the remaining mid-level methods to improve usability. They also refined the ClassSignature class model, which has been improved to model the generic signatures of superclasses and superinterfaces more accurately. According to the OpenJDK proposal behind this feature, the Java platform should define and implement a standard class-file API that evolves together with the class-file format, which can evolve every six months.
Also cited for inclusion in JDK 23 is another preview feature, primitive types in patterns, instanceof, and switch. This feature would enhance pattern matching by allowing primitive type patterns in all pattern contexts, and extend instanceof and switch to work with all primitive types. Goals include providing easy-to-use constructs that eliminate the risk of losing information due to unsafe casts; aligning pattern types with instanceof; aligning instanceof with safe casting; allowing uniform data exploration by allowing type patterns for all types, whether primitive or reference types; allowing pattern matching to use all primitive type patterns in nested and top-level contexts; and following the enhancements to switch in Java 5 (enum switch) and Java 7 (string switch) to process values of any primitive type.
String templates, which was previewed in both JDK 22 and JDK 21, was dropped from consideration for JDK 23. The feature was intended to complement Java’s string literals and text blocks by coupling literal text and embedded expressions to produce specialized results. The OpenJDK community felt the capability was “not pulling its weight” and that further evaluations and a potential redesign would take time.
Java steward Oracle also has revealed plans for Java in 2024. Oracle outlined improvements that involve OpenJDK projects ranging from Amber, for developing smaller, productivity-oriented features, to Babylon, for extending Java to foreign programming models such as GPUs, to Valhalla, for augmenting the Java object model with value objects to eliminate longstanding performance bottlenecks.