Project Valhalla: A Decade-Long Java Evolution Targets JDK 28

A Decade of Java Evolution Nears Fruition

On June 15, Oracle engineer Lois Foltan confirmed a milestone many in the Java community had begun to doubt would ever arrive. JEP 401: Value Classes and Objects is targeting integration into OpenJDK's main repository for JDK 28, scheduled for release in March 2027. This marks the first, long-awaited deliverable from Project Valhalla, an initiative launched in 2014 to fundamentally reshape Java's performance model.

The integration is so significant that committers were asked to pause major commits during the process. The associated pull request adds over 197,000 lines of code across 1,816 files. However, as language architect Brian Goetz cautioned, this is "only the first part of Valhalla" and will be a preview feature, disabled by default.

This development concludes over a decade of research and five distinct prototypes. The project's core ambition has remained constant: to allow developers to write classes that "code like a class, but work like an int." The goal is to erase the historical dichotomy between convenient, safe objects and fast, dense primitives.

The Fundamental Problem: Fluffy vs. Dense Memory

Java's performance model has been at odds with modern hardware for years. Since 1995, with the exception of eight primitive types, everything in Java has been a reference type. A variable like Point p is a pointer, not the data itself.

This leads to what Brian Goetz calls a "fluffy" memory layout. An array of a million Point objects is an array of a million pointers to a million individually allocated objects scattered across the heap. Each object carries a header for metadata and incurs allocation and garbage collection costs.

Modern CPUs, however, thrive on locality of reference. Data accessed sequentially and stored contiguously in cache lines (often 64 bytes) performs orders of magnitude faster than data requiring pointer indirection and risking cache misses. Valhalla aims to provide a "dense" layout, where object fields sit side-by-side in memory.

While escape analysis can sometimes optimize this away, it is fragile and unpredictable. Valhalla's value classes offer a predictable, declarative path to these performance characteristics.

Value Classes: The JDK 28 Preview

So, what exactly arrives in JDK 28? Developers gain the ability to declare a value class. This looks like a normal class but comes with specific constraints: its instances are value objects without identity.

All instance fields are implicitly final, the class is final by default, and methods cannot be synchronized. The most profound change is to the == operator, which now performs a substitutability comparison, checking if two value objects are of the same class with recursively equal fields.

A critical nuance, and a common point of confusion, is that in the JDK 28 model, a value class is still a reference type. Value objects can still be null. The feature enabling non-nullable types, JEP 8316779 "Null-Restricted Value Class Types," is a separate, future proposal.

Performance Mechanisms: Scalarization and Flattening

The JVM gains two powerful optimization avenues for value objects. Scalarization allows the Just-In-Time (JIT) compiler to break down a value object reference into its constituent fields, effectively eliminating allocation and garbage collection overhead across method boundaries.

More impactful for data-intensive workloads is heap flattening. Here, the JVM can encode a value object's data as a compact bit vector and store it directly within a field or array element, eliminating the pointer. A Point[] can become a contiguous block of integers.

There is a catch: flattened data must be atomically readable and writable to prevent "tearing." On current hardware, this often limits flattening to values of 64 bits or less (including a null flag). This is where future null-restricted types become a performance lever, potentially allowing larger types to flatten by sacrificing atomicity.

The Long Road: Evolving Ideas and Nomenclature

The path to JDK 28 was not linear. Early prototypes explored a "Q World" model, treating value types as completely separate from objects. The breakthrough came with the "L World" prototype around 2019, which unified value types and object references under the same JVM type carrier.

Nomenclature evolved significantly. Terms like "value types," "inline classes," and "primitive classes" have been used and retired. The "two-projection" model (e.g., Point.val and Point.ref) was powerful but mentally taxing for developers and was ultimately simplified.

The current model in JEP 401 is the result of this rigorous simplification. As the article notes, "twelve years wasn't twelve years of 'writing code.' It was twelve years of rejecting ideas, until the one that can actually be maintained was left."

The Missing Half: Specialized Generics and the Future

While value classes are a massive step, a major performance ceiling remains due to Java's type erasure. In a List<Point>, the type parameter T erases to Object, forcing the JVM to materialize value objects on the heap.

Unlocking flat, allocation-free generic collections requires the second phase of Valhalla: specialized generics. This involves both Universal Generics (allowing type variables to cover value types at the language level) and Specialized Generics (generating optimized, type-specific layouts at the JVM level).

This work is still in progress and is not part of JDK 28. Its arrival will be crucial for frameworks and libraries to fully leverage Valhalla's potential.

Immediate Impact and Ecosystem Migration

The immediate effect in JDK 28 preview includes the migration of JDK's own "value-based" classes. Notably, the primitive wrapper classes (Integer, Long, etc.) will become value classes when preview is enabled.

This means Integer[] will begin to approach the memory efficiency of int[], and boxing overhead will "shrink dramatically." The accompanying JEP 402, "Enhanced Primitive Boxing," further smoothes these conversions.

For developers, the key takeaway is to internalize the identity versus value distinction. Code that relies on object identity (using == for reference comparison or synchronized blocks) may need adjustment. The new Objects.requireIdentity() helper can enforce identity where needed.

Looking Ahead: A Foundation Shift, Not a Feature

Project Valhalla represents one of the most profound changes in Java's history. It doesn't add a feature; it moves a foundational assumption that has stood since 1995: that every object has identity. Allowing developers to opt-out of this contract unlocks a new era of performance.

JDK 28 is a non-LTS release, with the next LTS likely being JDK 29 in September 2027. This preview phase is critical for gathering real-world feedback before the feature stabilizes. For domains like data processing, machine learning, game development, and finance, the ability to write abstract, safe code without sacrificing memory density is a long-held dream now within reach.

The journey is not over, but a major milestone has been passed. As the article concludes, early-access builds are available, allowing developers to experiment with this new model before it becomes mainstream.