JEP 401 value classes hit JDK 28 preview, but Brian Goetz warns it stays preview

Java’s Project Valhalla just moved from myth to calendar: Oracle engineer Lois Foltan confirmed that JEP 401, Value Classes and Objects, will be integrated into the OpenJDK mainline early next month, with the target landing spot of JDK 28. Previews of JEP 401 have already existed in early-access builds, but this is the point where the work stops being “somewhere over there” and starts becoming part of the mainline delivery machine.

And then comes the part that matters to anyone building roadmaps, not just compilers: Brian Goetz, Java Language Architect at Oracle, warned that it will likely still be a preview in the next LTS release. In other words, you are getting a real preview in JDK 28, but you should not assume “preview” will reliably turn into stable, LTS-grade reality on the same schedule teams usually plan around.

Let’s anchor the timeline in the source’s numbers. The current JDK is 26. JDK 27 is expected in September. JDK 28 is expected in March 2027. The next long-term support version is likely to be JDK 29 in September 2027. Goetz’s “Hoping for it to exit preview for 29 seems … optimistic” is essentially telling decision-makers to discount any internal plans that assume preview will become production-safe before the next LTS window.

This is not a small feature toggle. Foltan described JEP 401 as “an extremely large change,” enough that other OpenJDK committers were asked to avoid large commits to help a successful integration. The first preview pull request for JEP 401 reportedly adds more than 197,000 lines of code across 1,816 changed files. When you see that scale, you should interpret the preview warning less as caution theater and more as a reflection of how many moving parts must click together for a language change that goes beyond surface syntax.

So what is JEP 401 actually doing? It tackles a longstanding Java limitation: most types are reference types, meaning they have object identity. Java has a small set of primitive types, such as int, char, byte, and double, but aside from those, the language treats almost everything as references. JEP 401 introduces “value objects,” class instances that lack object identity and are distinguished solely by the values of their fields. Practically, this is about eliminating a bunch of “why does this compare differently?” footguns.

The source gave two concrete examples that show why identity is the trouble. First, Java’s LocalDate stores a date value, but each instance has its own unique reference, so comparing two LocalDate instances with == returns false even when they represent the same data. You end up using equals instead. Second, Integer wraps an int to provide convenience methods like toString(). Internally, Integer caches instances for values below 128, so two Integer objects with the same small value can compare equal with ==. For larger values, == always returns false even when underlying values match. The JEP calls that an “unwanted complexity,” which is a polite way of saying “this surprises people all the time.”

JEP 401 plans to migrate some JDK classes such as Integer to value classes, and the number of migrated classes is likely to increase gradually. Developers will also be able to create their own value classes. But the bigger promise is about performance and the freedom it gives the JVM. The JEP’s goal is to let the JVM store value objects in ways that maximize performance. Reference types tend to have a greater memory footprint, and they must be dereferenced to obtain their values. Iterating over value types is more efficient. If your org runs latency-sensitive Java workloads, this is the kind of “compiler/runtime shape-shifting” that can matter as much as algorithm improvements.

Now the trade-off that turns this from an engineering upgrade into a governance and compatibility problem: Goetz said fully treating objects with value semantics requires giving up more, specifically nullity and atomicity-safety-under-race (ASUR). He also warned about packaging it in the user model so it does not fight Java’s assumptions about object integrity and encapsulation, calling out that “classes are, for better and worse, a very effective abstraction barrier.” In plain terms, the runtime can optimize, but Java developers have mental models and language contracts to reconcile.

And there is the deliberate breaking-change signal, which should make enterprises pay attention. Goetz said Valhalla will introduce breaking changes such as “code that synchronizes on Integer objects now fails with an exception.” That means libraries and internal code patterns involving synchronization on specific JDK classes could become landmines as migrations occur.

So where does this leave boards, CTOs, and platform teams? JEP 401 is integrating into OpenJDK mainline with a JDK 28 target, and previews are already circulating, but the likely preview hangover into the next LTS cycle increases the planning uncertainty. If your risk posture is “stabilize on LTS, minimize surprises,” you may need a strategy that treats JDK 28 preview as experimentation, not as a foundation for guaranteed long-term behavior.

For peers who oversee Java platforms across business-critical systems, the second-order implication is straightforward: you will need to track not just the JDK versions, but the semantics shift that value classes bring, including the breaking-change category and the preview-to-LTS uncertainty. Valhalla may be the “first part,” as Goetz framed it, but even that first part is already large enough to force how teams plan, test, and upgrade.