Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

JEP 401: Value Classes and Objects has been integrated into the main OpenJDK repository and is targeting JDK 28, Oracle engineer Lois Foltan confirmed on June 15. The change is large enough that other committers were asked to hold off on bigger commits while it landed: the pull request alone adds more than 197,000 lines of code across 1,816 files.

The feature arrives as a preview, disabled by default, so it will only run with the --enable-preview flag. Brian Goetz, who reviewed the JEP, was quick to temper expectations, describing it as "only the first part of Valhalla."

The problem: everything is a reference

Valhalla's slogan has always been "codes like a class, works like an int." In Java, apart from the eight primitives, every value is a reference: a variable holds a pointer to an object on the heap, each object carries its own header, and every object must be allocated and later garbage collected. An array of a million points is, in practice, a million pointers to a million boxes scattered across memory — a layout Brian Goetz has called "fluffy."

Density matters because hardware changed faster than the language: processors read memory in 64-byte cache lines, so contiguous data arrives several values at a time, while pointer chasing risks cache misses that can be a hundred times slower than a hit.

What JDK 28 brings

JEP 401 introduces one new concept: a value class, declared with the value modifier, whose instances are value objects without identity. Two separately created value objects with the same fields are interchangeable, so == becomes a substitutability test rather than an address comparison, and synchronized on such a type throws an IdentityException. Value classes are final by default, their fields are implicitly final and their methods may not be synchronized; they can still be null, because non-nullable, null-restricted types are a separate and later JEP.

The JVM gains two optimizations. Scalarization lets the JIT break a value object into its fields, removing the allocation altogether; heap flattening writes the value directly into a field or an array cell. Flattened data must be read and written atomically, which today means roughly 64 bits including the null flag, so some small classes still end up on the heap. With preview enabled, the JDK's own wrapper classes such as Integer become value classes, which should make boxing much cheaper.

What is still missing

Specialized generics are not part of JDK 28. Because Java generics use type erasure, a value object placed in a generic collection is still materialized on the heap, so an ArrayList of points will not be flat yet; flattening works directly for fields and arrays of a value type. Null-restricted types, 128-bit encodings and a fully mature JEP 402 on enhanced primitive boxing are also future work.

The project itself dates back to 2014 — James Gosling described it at the time as "six PhDs tied into a single knot" — and went through five prototypes before it reached its current shape. JDK 28 is not a long-term-support release: it is scheduled for March 2027, with the next LTS expected to be JDK 29 in September 2027. Early-access builds are already available at jdk.java.net/valhalla.