Two LocalDate values that represent the same day compare as not-equal under Java's == operator, because the operator checks object identity rather than contents. Two Integer values, meanwhile, flip their comparison behavior above 128 because of how the language caches small numbers. That kind of identity-versus-value confusion has tripped up working Java developers for years, and it is exactly what Project Valhalla's Value Classes and Objects proposal, JEP 401, is designed to retire. The first preview of JEP 401 will merge into the OpenJDK mainline in early July, targeting JDK 28, the OpenJDK Java release scheduled for March 2027.
The preview is a serious engineering event by any measure. The first-preview pull request, reported by The Register, adds more than 197,000 lines of code across 1,816 files. Oracle software engineer Lois Foltan, who is leading the integration, asked other OpenJDK committers to avoid large commits during the integration window to reduce the risk of merge conflicts, and described the change as "extremely large."
What changes for developers is the comparison story. In current Java, every type other than a small set of primitives (int, char, byte, double, and so on) is a reference type: each value lives on the heap, carries an object header, and is identified by where it sits in memory rather than by what it contains. Value classes let user-defined types behave more like primitives, with flattened memory layout, no object-header overhead, and equality defined by the values themselves.
JEP 401 has been a long road. Project Valhalla itself launched in 2014, and the JEP 401 draft was first circulated in 2022, with the formal JEP following later. The Register's piece notes the formal JEP 401 page on openjdk.org is now the authoritative artifact. The original source contains what looks like a typo on JEP 401's creation date, so this article does not assert a specific year for the formal JEP beyond the 2014 Project Valhalla launch and the 2022 draft circulation.
The release track matters here. The current production JDK is version 26. JDK 27 ships in September 2026, JDK 28 in March 2027, and the next long-term support release is most likely JDK 29, scheduled for September 2027. Java Language Architect Brian Goetz, quoted in The Register's coverage, warned that JEP 401 is likely to still be in preview even in that next LTS. In practice, that pushes production-ready value classes to 2028 or later for any team that waits for an LTS to adopt new language features.
The migration is gradual rather than forced. Some classes will be migrated by the JDK itself — including Integer, Long, Float, Double, Byte, Short, Character, Boolean, Optional variants, and LocalDate, LocalTime, LocalDateTime, ZonedDateTime, and Duration — while custom value classes remain a developer choice. Developers who hit the Integer or LocalDate confusion in their own code today are still on the hook to work around it; the preview is the first step toward a future where the workaround is no longer needed, not a switch that flips next month.
For teams planning Java roadmaps, the honest question is what to do with the next two release cycles. JDK 27 in September 2026 will not include JEP 401. JDK 28 in March 2027 will include the first preview, behind preview flags, with the same language-evolution caveats that have applied to every Java preview feature since the release cadence shifted to twice yearly. Teams that already enable previews on a non-production branch can start reading their own code through a value-class lens. Teams that wait for LTS to adopt new features should plan for JDK 29 in September 2027 at the earliest, and Goetz's own framing suggests even that window may slip.