The number of proposed features for Java Development Kit (JDK) 23, the next planned version of standard Java, has climbed to seven. The two latest additions are module import declarations and markdown declaration comments. A proposal to make the generational mode of the Z Garbage Collector the default mode was added last week.
Due September 17, JDK 23 also will include a vector API, which will be incubated for the eighth time, a second preview of stream gatherers, a second preview of a class-file API, and a preview of primitive types in patterns, instanceof, and switch. Early access builds for JDK 23 can be accessed from jdk.java.net.
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 and updated last week, 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 and updated last weekend, 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 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, and allowing uniform data exploration by allowing type patterns for all types, whether primitive or reference types. Another goal is allowing pattern matching to use all primitive type patterns in nested and top-level contexts.
A number of other features previewed in JDK 22 could make it into JDK 23. These include statements before super(…), which would give developers greater freedom in expressing constructor behavior; string templates, which would make it easy to express strings that include values computed at run time; scoped values, which would enable sharing of immutable data within and across threads; and implicitly declared classes and instance main methods, which would make it easier for beginning programmers to write programs without needing to understand language features designed for large programs. Derived record creation and a hot code heap proposal, which would reduce application execution times, also are possibilities.
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.