Java Value Objects: JEP 401 Lands in OpenJDK Master

If you run Java in production, you know the feeling: objects that exist only to carry a pair of values, yet they devour your memory and hammer the garbage collector. For years, the community has been pushing for a native solution inside the JVM. That solution just hit a major milestone: JEP 401 (Value Objects) is now merged into the main OpenJDK branch, in preview for JDK 28.

On July 31, 2026, after months of intense development on the Valhalla branch, commit cc278dbb sealed the integration. This isn’t just a proposal: it’s real code, compiled, reviewed by roughly twenty contributors, and available in early-access builds. Let’s break it down.

What is JEP 401 Value Objects?

JEP 401 introduces the concept of value objects to the Java language and JVM. A value object is an object without its own identity. With a regular class, two instances are distinct even if their fields are identical (they have identity through their memory reference). Two value objects with the same values are considered equal by construction.

This distinction changes everything:

No more handcrafted equals() and hashCode() to compare by content
The JVM can optimize memory layout (no more pointers, no more wasted padding)
The garbage collector has less work, since these objects can be stored directly inside arrays or other objects, without indirection

The promise is straightforward: dramatically better performance for simple data types, without sacrificing readability or type safety.

A historic merge into OpenJDK master

The main pull request (openjdk/jdk#31120), led by David Simms (Oracle), brought all the changes together. To make review manageable, the team split the work into three sub-PRs:

JDK-8317277: language-side implementation (javac compiler)
JDK-8317278: JVM-side implementation (HotSpot)
JDK-8317279: standard library implementation

In total, over 50 contributors participated in the effort, with high-profile reviewers like Maurizio Cimadamore, Joe Darcy, Dan Heidinga, and Coleen Phillimore. The PR received approval from 14 reviewers, a number that speaks to the complexity and breadth of the change.

The final commit, pushed on July 31, 2026, sets the stage for JDK 28, where the feature will ship as a preview.

JEP 539: the essential companion

Merged at the same time, JEP 539 (Strict Field Initialization) is no minor technical footnote. It enforces strict field initialization rules, guaranteeing that a value object can never be observed in a partially constructed state.

Why does this matter? Because a value object has no identity. If one thread could see a zeroed-out field while another thread is still constructing it, the entire value semantics would collapse. JEP 539 locks down this behavior at the JVM level, making value objects reliable by default.

These two JEPs are inseparable. The Valhalla team developed them in the same codebase (valhalla/lworld branch), and their joint integration into master reflects this functional dependency.

Why this is a turning point for the Java ecosystem

Value types have been the JVM’s white whale. Project Valhalla started nearly ten years ago, and many developers had started to doubt it would ever ship. The merge into master changes everything: this is no longer an experiment, it’s a feature on the path to GA.

Here’s what this will change in practice:

More efficient collections: an ArrayList<Point> where Point is a value object will store coordinates without interleaved pointers, with far better memory locality for the CPU
Reduced GC pressure: fewer objects on the heap means fewer garbage collection cycles, which means fewer pause times
More natural modeling: types like Complex, Money, Color, or Duration will no longer need to be emulated through hand-rolled immutable classes
Interoperability with primitives: eventually, Project Valhalla aims to unify how primitives and value objects are handled, which future JEPs will build upon

The community saw this for what it is. As soon as the announcement hit, developers celebrated an advance that removes what many considered “the biggest obstacle to certain kinds of performance” in the JVM.

How to test Value Objects right now

If you want to get your hands dirty, here are your options:

Grab an early-access build of JDK 28 from jdk.java.net (builds already include the preview)
Build from source from the OpenJDK repository, using the tag corresponding to commit cc278dbb
Enable the preview in your project with the --enable-preview flags at both compile time and runtime

The exact syntax is still stabilizing, but expect to see a value modifier on classes or records in the coming months. Early-access builds will give you an accurate picture of what’s coming in JDK 28.

Key takeaways

JEP 401 Value Objects is merged into OpenJDK master as of July 31, 2026, in preview for JDK 28
It ships alongside JEP 539 (Strict Field Initialization), which is essential to the model’s reliability
Project Valhalla has finally delivered a piece that’s been anticipated for nearly a decade
Expected gains cover memory, GC pressure, and data locality
Early-access builds of JDK 28 already let you test the feature

Already experimenting with value objects or following Project Valhalla? I’d love to hear your thoughts. Feel free to share this post or reach out to discuss.