By Twelve years. That is how long Java developers have been promised Project Valhalla. This month, JEP 401 — Value Classes and Objects — was integrated into OpenJDK mainline, targeting JDK 28. The pull request added 197,000 lines of code across 1,816 files. The payoff: Java objects that behave like primitives, eliminating the boxing overhead and heap fragmentation that has pushed performance-sensitive teams toward Rust and Go for a decade. Here is what actually shipped, who it matters to, and whether you should touch it before 2027.
What Value Classes Are
Brian Goetz, Java’s language architect, has described the goal for twelve years with the same phrase: “codes like a class, works like an int.” JEP 401 delivers the first half of that promise.
A value class is an identity-free, immutable object. The JVM does not need to allocate it on the heap. Instead, the JIT compiler can scalarize it — decomposing the object into its constituent fields and passing them directly as register values, eliminating allocation entirely. When value objects live in arrays, the JVM can flatten them into contiguous memory, replacing arrays of pointers to scattered heap objects with dense, cache-friendly blocks of data.
Two forms are available. The minimal syntax is a value record:
value record Point(int x, int y) {}For more control, a value class:
value class Money {
final long amount;
final String currency;
Money(long amount, String currency) {
this.amount = amount;
this.currency = currency;
}
}The rules are stricter than a regular class: all instance fields are implicitly final, synchronized is forbidden, and == compares field values rather than references. If your code uses synchronized(somePoint), it will break. If it uses pointA == pointB expecting reference identity, it will silently change behavior. Read the JEP before migrating anything.
Why Boxing Overhead Matters More Than You Think
Every Java developer knows boxing is a performance tax. You create a List<Integer>, not a List<int>, because generics cannot hold primitives. Each Integer wraps a 4-byte int in a 16-byte object header, lives somewhere on the heap, and requires a pointer to reach. An array of a million integers becomes an array of a million pointers pointing to a million scattered objects. That is the opposite of what modern CPUs want.
Value classes break this pattern. Oracle’s own benchmarks show that converting LocalDate to a value class and storing instances in an array produces a roughly 3x speedup because the JVM eliminates the extra memory indirection. For applications processing millions of small objects per second — financial tick data, sensor streams, ML inference batches — this is not a micro-optimization. It is a structural change in how the JVM handles your data.
C# solved this with struct in 2002. Java took 24 years longer. But here is the thing: C# required developers to choose struct or class upfront and live with that choice. Java’s value classes are being introduced into a runtime that has been running for three decades with a fundamentally different model. Shipping value classes without breaking compatibility is genuinely harder, and the team has done it without requiring existing code to be rewritten.
Who Should Try This Now
The preview is available today in JDK 28 early-access builds. To enable it:
java --enable-preview --release 28 MyApp.javaIf you are in any of these categories, start running experiments now:
- Finance and trading systems processing high-frequency tick data or pricing structs
- Game engines and simulations with millions of small objects per frame — vectors, positions, colors
- ML inference on the JVM — tensor slices, feature vectors, embedding dimensions
- Data pipeline engineers whose hot paths are dominated by GC pressure and boxing churn
- Library and framework authors — Spring, Quarkus, and Netty maintainers need to understand how value types will change their APIs before the feature exits preview
If you are building standard web applications, CRUD services, or microservices without a documented performance bottleneck in object allocation, there is nothing to do right now. Wait for LTS.
What Is Not Here Yet
Goetz was blunt in his announcement: this is the first part of Valhalla. The feature developers actually want most — universal generics, meaning List<int> or Map<long, double> without boxing — is a separate JEP that does not exist in JDK 28. Value classes are the foundation; primitives in generics is the structure built on top.
The migration of the JDK’s own primitive wrapper classes (Integer, Long, Double) to value classes is included in this preview. That is significant because it means the boxing tax on standard library types will eventually disappear. But “eventually” means after the feature exits preview — likely not before the ecosystem fully absorbs the change. JDK 29 arrives in September 2027 and will probably keep value classes as preview too.
Goetz put it plainly: “The ‘they’ll never ship it’ crowd will switch to ‘but they didn’t ship the most important part.'” He is right. Celebrate the milestone, build experiments, but do not rewrite production systems yet.
The Bottom Line
Project Valhalla delivering a preview in JDK 28 is a genuine milestone for Java. The performance implications for data-intensive, allocation-heavy workloads are real and measurable. If you have performance-critical Java, now is the time to start benchmarking your hot paths against the early-access builds and filing feedback at the valhalla-dev mailing list.
For everyone else: watch this space. The JVM’s performance ceiling is about to get substantially higher. It just might take until 2028 to feel it in production.
