It’s Here (Finally), But Don’t Pop the Champagne Yet
Lois Foltan, the Oracle software engineer shepherding Java’s longest-running modernization effort, has officially confirmed that JEP 401 — the Value Classes and Objects proposal under Project Valhalla — will integrate into the OpenJDK mainline early next month, in time for JDK 28’s March 2027 release.
Yes, it’s taken this long. So long that developers have joked about needing a trip to Valhalla itself (the Norse afterlife) before the project ships. Now it’s finally arriving, and if you’ve ever written new Integer(42) only to be surprised that == doesn’t behave how you expected, this matters.
But here’s the thing: just because it lands in JDK 28 doesn’t mean you can flip a switch and adopt it in production. Project Valhalla’s architect, Brian Goetz, is already tempering expectations: the preview will likely remain in place even through the next long-term support (LTS) release, JDK 29 in September 2027.
We’re not looking at a quick upgrade. We’re looking at a carefully orchestrated landing — because the change isn’t small.
How Big Is This Change, Really?
Let’s be blunt: this is massive under the hood. The initial pull request that introduces JEP 401 adds over 197,000 lines of code across 1,816 changed files in the OpenJDK repository. That’s not a patch or a tweak; it’s one of the largest in-core refactorings Java has ever seen.
That’s why other OpenJDK committers are being asked to hold off on large commits during the integration window — any extra churn could destabilize a foundational layer. Think of it like landing a plane: small, precise movements only.
But the scale makes sense once you understand what value types actually do — and, more importantly, what they don’t. Prior to this change, Java’s type system is split in a weird way: primitives (int, char, byte, double) exist on the stack, inlined and fast. Everything else — including boxed versions like Integer, LocalDate, and countless domain objects — is a reference type, allocated on the heap with object identity.
That split created real pain. You know the drill: LocalDate objects may represent identical dates, but without a custom equals(), they’re just different memory addresses. And then there’s Integer, where values under 128 cache and compare with ==, but anything larger doesn’t. This inconsistency isn’t just confusing — it’s a class of bugs Java developers have been dodging for decades.
What Exactly Is a Value Object?
JEP 401 defines value objects as instances that lack object identity. In other words, they’re distinguished solely by the values of their fields — not where they sit in memory. No identity means no System.identityHashCode(), no lock semantics, and no null guarantee for free.
This isn’t just academic./value types unlock new performance pathways for the JVM:
- Fewer allocations: No heap pointer, no separate metadata header. Value objects can be stored directly inside arrays or inline in containing structures.
- Better cache locality: When iterating over collections of primitives or small structs, the CPU doesn’t chase references all over memory.
- Escape analysis on steroids: The JIT can keep values in registers, eliminate allocations entirely, or even flatten nested structures.
That last point — escape analysis — has long been part of Java’s optimization story. But it was fragile, context-dependent, and often too conservative. Value types bake in a stricter guarantee: if an object is never exposed beyond its scope, it won’t be heap-allocated. That’s a huge win for latency-sensitive code and high-throughput systems alike.
So… What Actually Changes for Developers?
You won’t be writing value types by default overnight. JDK 28’s preview mode means developers get early access to experiment and provide feedback, but production usage remains cautious.
The plan? Start with high-impact JDK classes. The article hints that Integer and likely LocalDate are prime candidates for migration to value semantics. That means future Java versions could start shipping faster, leaner core APIs — no more surprise boxing and unboxing overhead.
Later, developers will gain the ability to declare their own value types. Expect keywords like value class or value record, borrowing some of the clarity from Java’s existing records. That’s where things get interesting — domain models with true value semantics, immutable by design.
But it won’t be all roses. As Goetz points out, this does mean breaking some existing patterns:
“Code that synchronizes on
Integerobjects now fails with an exception.”
Yeah, you read that right. Synchronizing on boxed primitives was always a bad idea — but now the runtime enforces that by throwing an exception. There will be migration pain, which is why Java’s team wants to surface it as gently as possible.
Project Valhalla: One Step, Not the Whole Journey
Brian Goetz makes it clear this is “just the first part of Valhalla.” Removing identity (object identity) is step one. The bigger challenges lie in surrendering two more things:
- Nullity
- Atomicity-safety-under-race (ASUR)
C# structs have been doing something similar for years, and TypeScript’s recent record-like hints show how value semantics are becoming table stakes for modern languages. But Java’s scale — literally billions of bytes in production, across decades of evolution — means each step is weighted with backward compatibility concerns.
Goetz puts it bluntly: “The main challenge is how to package it in the user model so that it doesn’t fight with our own preconceived notions of object integrity and encapsulation.”
In plain English: developers think in objects, and Valhalla asks them to think differently. It’s like asking for a new grammar in the language you’ve used daily — even if it makes your code smaller and faster.
Why Wait So Long for a Preview?
The delay wasn’t bureaucracy — it was complexity masquerading as caution. Every change in the runtime affects the compiler, the JIT, tools like profilers and debuggers, even popular frameworks. Merging a new object model into an ecosystem as mature as Java’s requires time.
Remember: the JEP was created in August 2022, but its roots go back years earlier. The team has been iterating silently on test branches, perf profiles, and reference implementations.
And even now that the preview lands in JDK 28, vector API — a key beneficiary of Valhalla’s VM primitives — will still need to rebase on those underlying changes. Goetz discourages hopes for a shorter preview window, confirming: “don’t hope for a shorter-than-usual preview window.”
The Long Game
If you’ve ever written int[] instead of List<Integer> for performance, or worked around the non-identity issue of domain objects with utility libraries — this is the payoff. Not tomorrow, maybe not even next year, but eventually.
Project Valhalla won’t rewrite Java overnight. It will refine it — making it faster, leaner, and safer for the next decade of cloud-native, high-throughput applications.
The fact that it’s finally here in preview form is a quiet win for the Java ecosystem. A language built to be boring and dependable isn’t done innovating — it’s just doing so in a way that respects its heritage.
So no, don’t hold your breath for instant production use. Do start reading up on value types now. Because when they arrive, Java won’t be the same — and you’ll want to know why.
