Twelve Years in the Making: JDK 28 Ships Value Classes Preview

A technical deep dive into the features shaping the next Java feature release, due March 2027 — including the twelve-year backstory behind its headline feature.<br>JDK 28 is a non-LTS ("feature release") of the Java Platform, tracked as JSR 403 in the Java Community Process. It follows JDK 27 (due September 15, 2026) on Java's strict six-month release cadence, and — like every other non-LTS release since Java moved to time-boxed shipping — it will get only six months of Oracle support before end-of-life. The next Long-Term Support release isn't due until JDK 29 in September 2027.<br>The JDK 28 Expert Group was formally approved in early June 2026: Iris Clark (Oracle) as specification lead, alongside Simon Ritter (Azul Systems), Stephan Herrmann (Eclipse Foundation), and Christoph Langer (SAP SE). Early-access builds have been available since Build 0 in early June 2026, and the release schedule currently calls for a public review period running December 2026 through February 2027, ahead of general availability in March 2027.<br>As of early August 2026, three JEPs are formally Targeted to JDK 28, and a fourth sits at Candidate status awaiting a proposed-to-target vote:

JEP<br>Title<br>Status<br>Type

401<br>Value Classes and Objects<br>Targeted<br>Preview language & VM feature

539<br>Strict Field Initialization in the JVM<br>Targeted<br>Preview VM feature

535<br>Shenandoah GC: Generational Mode by Default<br>Targeted<br>Default change / deprecation

542<br>PEM Encodings of Cryptographic Objects<br>Candidate<br>Finalization (from preview)

Three or four targeted JEPs this early is typical for a non-LTS cycle — JDK 26 shipped ten JEPs total by the time it froze, JDK 27's set was leaner still — and the list above is a snapshot, not a final manifest; the feature set won't lock until Rampdown Phase One, expected ahead of the December 2026 public review.<br>By far the most consequential item, and the one this article spends the most time on, is the first preview of value objects — the flagship deliverable of Project Valhalla , arriving after twelve years of development.<br>JEP 401 — Value Classes and Objects (Preview)<br>Why this took twelve years<br>Officially, Project Valhalla began in 2014. James Gosling reportedly described the effort at the time as "six PhDs tied into a single knot" — not an exaggeration. The goal was to close a gap that had existed in Java since 1995: primitive types (int, long, double, boolean, and friends) are stored by value — fast, compact, no allocation — while everything else is a reference type, stored as a heap pointer carrying a unique identity. Java's own designers wanted value types in the original language but shelved the idea in 1995 because the problem was too hard to solve alongside everything else.<br>The team built five distinct prototypes over the following decade, each probing different corners of the design space:<br>"Q World" (early prototypes) treated value types as a fundamentally separate kind of thing from objects — their own descriptors, their own bytecodes, their own type hierarchy root, mirroring how primitives already worked. It flooded the JVM's type system with duplicated machinery: nearly everything needed two variants.<br>"L World" (~2019) , the breakthrough, unified value types under the same "L carrier" the JVM already uses for object references. The team expected this unification to be too constraining and were surprised when it worked cleanly — while also revealing that the language model and the JVM model don't need to match one-to-one. The JVM's L World representation could simply be a compilation target, with the language layer free to offer programmers something more ergonomic on top. That separation of concerns shaped everything that followed.<br>The naming also went through several complete rewrites, each tracking a real change in the underlying model:<br>"Value types" — the vague, earliest term.<br>"Inline classes" (~2019–2020) — the identity/no-identity split crystallizes, along with the "codes like a class, works like an int" slogan.<br>"Primitive classes" and dual projections (2021 State of Valhalla) — the most ambitious, and ultimately abandoned, design. Every type would have two projections: a value form (flat, never null, primitive-like — written Point.val or Point!) and a reference form (a nullable box — Point.ref or Point?). Powerful, but the team concluded it was too mentally heavy for day-to-day programming — juggling two forms of one type and reasoning about implicit conversions between them. In line with Valhalla's guiding principle — simplify the model for the human, even at some cost to the performance ceiling — the dual-projection design was scrapped.<br>"Value classes" and "value objects" (today's JEP 401) — a single new concept: a value modifier on a class, whose instances lack identity but remain, importantly, a reference type that can still be null. Non-nullability became a separate, optional, later JEP instead of being baked into the core model.<br>If...