Early Access Release

The latest early access release of Valhalla features, codenamed LW4, is published at jdk.java.net.

Functionality, language syntax, and class file formats are subject to change. Many supplementary tools and APIs do not fully support the new features. The goal of this release is to solicit feedback and establish a milestone as we work toward a preview release in Java SE.

LW4 Functionality

This release is primarily focused on implementing the Value Objects JEP. (See the specification changes for more precise details.)

Java programs can declare concrete value classes, and can also use the identity and value keywords in other class and interface declarations. Various constraints are enforced on the declaration and use of classes with these modifiers, as described by the JEP. At run time, value objects have the specified identity-free behavior (can be equal to separately-created instances, will throw on synchronization attempts), and typically have inline, allocation-free encodings when stored in local variables or passed between methods.

Interested users are encouraged to explore the performance and migration impact of value objects on their applications, and to provide feedback to valhalla-dev@openjdk.java.net.

Support for flattened fields and arrays is still experimental, and must be activated using the command-line options documented below. The unlocked behavior is generally consistent with JEP 401 (as of November 2022): Classes may be declared primitive, uses of the primitive class name refer to a primitive value type, and .ref can be appended to a primitive class name to get its corresponding reference type. Primitive value types are null-free; covariant arrays of these types can be created (e.g., a Point[] can be treated as an Object[]). At run time, primitive-typed fields and arrays typically store their primitive values’ fields directly; reads and writes are not guaranteed to be atomic.

Command-Line Options

Special options supported by javac:

Special options supported by java:

Performance Guidance

As described by the JEP, HotSpot optimizes the stack encodings of value objects within C2-generated code, avoiding heap allocation. Most performance benefits will be observed in code that would traditionally require allocation of a large number heap objects, to be referenced by local variables and passed between methods.

Normal value objects will not be “flattened” into field and array storage. That behavior is part of the experimental Primitive Classes feature.

Note that HotSpot’s existing escape analysis and code inlining optimizations are quite effective at eliminating heap allocations for locally-contained identity objects. Performance improvements for value objects will primarily be observed in cases where these identity object optimizations would fail.