Java has long treated most data as objects with distinct identities. Two instances with identical field values still differ because each occupies its own spot in memory. That model brings safety. It also carries costs. Pointer chasing. Cache misses. Extra garbage collection pressure. Project Valhalla aims to change that equation.
Identity’s Hidden Price
Developers reach for classes like LocalDate or custom data carriers every day. They expect these to behave like values. Yet under the hood each remains a reference type. The == operator compares addresses, not content. Equality checks rely on equals and hashCode. Small objects allocated repeatedly inflate heap usage. Arrays of them scatter across memory. The JVM cannot freely rearrange or embed their state without breaking identity guarantees.
Records helped. They deliver immutable data with automatic methods. They still carry identity. Project Valhalla goes further. It introduces value classes. These lack any unique identifier. Two value objects are the same when their fields match. The distinction sounds academic. Its effects compound across large systems. The Next Web reported on June 15, 2026, that the change spans 197,000 lines of code across 1,816 files. Oracle engineer Lois Foltan called it “extremely large.”
And the timing matters. OpenJDK integration begins early July 2026. The feature targets JDK 28 as a preview. Current early-access builds already let teams experiment. OpenJDK’s Valhalla project page, updated May 29, 2026, notes a March 2026 build with bug fixes and enhancements. Developers download from jdk.java.net/valhalla and run with --enable-preview.
JEP 401 spells out the rules. Value classes use the value keyword. Fields are implicitly final. The class itself is final. No mutable state. No subclassing from identity classes. Abstract value classes exist for limited hierarchies. == performs statewise comparison. Synchronization on a value object throws an exception. The JVM gains freedom to flatten data into references or stack-allocate where possible. The JEP itself lists goals clearly: support migration of immutable JDK classes, maximize runtime optimizations, and give programmers a clean opt-in for pure data types.
Oracle’s Dan Smith explained the motivation in an October 2025 Inside.java post. “If your class represents immutable domain values that are interchangeable when they have the same state, giving these objects all the features of identity just adds unnecessary complexity.” He continued, “the JVM can optimize value objects in ways that are impossible for regular objects. For example, a reference to a value object doesn’t have to point to a canonical memory location for that object. Instead, the state of the object can be embedded in the reference itself. This technique is called heap flattening.”
Performance numbers remain workload-specific. Early tests on arrays of LocalDate show tighter layouts and fewer allocations. Scalarization lets the JIT treat small values like primitives. Cache lines stay hot longer. Garbage collectors see less live data. These gains accumulate in financial calculations, graphics coordinates, game entities, or high-frequency trading payloads. Yet not every class benefits. Objects with mutable fields or complex lifecycles stay identity classes.
The Register covered the news the same day. Its June 15, 2026, article noted that some JDK classes such as Integer will migrate to value classes. More will follow gradually. Brian Goetz, Java language architect, described this as “just the first part of Valhalla.” He warned that full value semantics require further steps around nullity and atomicity under race conditions. Exiting preview by JDK 29 looks optimistic. The Vector API, long incubating, can finally build on stable value types once the VM solidifies.
Breaking changes arrive with the feature. Code that synchronizes on Integer instances will fail. Reflection behavior shifts. Deep equality comparisons risk stack overflows on cyclic structures. Teams must audit carefully. The preview flag keeps production code safe for now. Feedback from real applications will shape final semantics. The Valhalla mailing list at [email protected] already receives reports.
So what does a value class look like? Simple declarations resemble records but carry different guarantees.
value class Point { private final int x, y; ... }
Or use value record for even less boilerplate. Instances behave like data. Their references can be copied freely. The JVM decides storage layout. No two distinct identities exist for the same numbers. Equality becomes intuitive. Maintenance drops because identity bugs vanish.
Java’s object model has stayed stable for decades. This shift touches the foundation. It echoes the introduction of generics or lambdas in impact, yet targets runtime efficiency more than syntax. Enterprises running massive Java fleets stand to gain most. Memory savings translate to lower cloud bills. Faster iteration means quicker analytics. Reduced GC pauses improve tail latencies.
Critics point to complexity. Preview status demands caution. Migration of legacy libraries takes time. But the alternative is continued inefficiency. Primitives avoid identity costs yet lack object benefits. Value classes bridge that gap. They keep the class abstraction while shedding its overhead where it no longer serves.
Recent discussions on X reflect guarded excitement. Engineers note the long road from 2014 announcement to 2026 preview. Others experiment with Protocol Buffers mapped to value classes and report promising density improvements. The community understands this isn’t a quick win. It is deliberate engineering that prioritizes compatibility and measurable gains.
Developers should start small. Profile existing hot paths. Convert pure data carriers first. Measure before and after with JMH and JDK Mission Control. Smith advised exactly that. “This is beta software, and it’s sure to have some bugs and surprising performance pitfalls. Now is a great time for interested users to download the early-access build and try it out on their performance-sensitive workloads.”
The road ahead includes more Valhalla components. Primitive classes, specialized generics, and further JVM enhancements will follow. JEP 402 on enhanced primitive boxing already ties in. For now the focus rests on value classes. Their arrival in JDK 28 preview marks a concrete milestone after years of prototypes and debate.
Java remains the backbone for enterprise systems precisely because it balances stability with steady progress. Value classes extend that tradition. They don’t rewrite the language. They refine its foundations so that common patterns run faster and consume fewer resources. Teams that adopt early will shape the final form. The rest will inherit a more efficient platform when the feature exits preview.
Watch the early-access builds. Read the JEP. Test on representative data. The payoff arrives one optimized array at a time.
WebProNews is an iEntry Publication