Java value classes ship in JDK 28, but not the flat ArrayList everyone wanted

One word that rearranges memory

The JVM Weekly explainer walks through what actually lands in JDK 28 after ten years of Project Valhalla. The core move: a class declared with the value modifier gives up identity. Its fields are implicitly final, you can't synchronize on it, and == compares contents instead of memory address. The slogan: "codes like a class, works like an int."

The payoff is layout. A Point[] today is an array of pointers to scattered heap objects, each with its own header. Mark Point as a value class and the JVM can store the values inline — roughly 8 bytes per point (plus a possible null flag), contiguous, no per-element headers, no pointer-chasing. The integration is enormous: 197,000 lines across 1,816 files, in 2,819 commits.

What you don't get yet

The one thing most readers wanted is explicitly deferred:

"Will I get a fast, flat ArrayList<Point>? Not yet. Sad. Hope they can do this by the next LTS JDK." — a commenter on the missing flat collections

Also not shipping: non-nullable value types, full specialized generics, 128-bit atomics. And the wrapper classes Integer, Long, Double quietly become value classes under preview — losing identity. A reader with 15k+ karma argued that single fact dooms the default-on dream:

"I'm sure it'll be trivial to turn this on in the wild on code that may be relying on identity for boxed numerics… now we'll have a decade of two Java languages (one with value types and one without)… ie python3." — a commenter who built out the Ship-of-Theseus critique

Project lead Brian Goetz had already braced for this, per the article: he called it "only the first part of Valhalla" and predicted the "they'll never ship it" crowd would pivot to "but they didn't ship the most important part."

The footnote that was wrong — and the AI images

The thread's most damaging catch was a factual error in the piece's own comparison. The article's footnote claims a C# struct "has identity." Two readers who'd used C# said that's backwards:

"Since when? I'm pretty sure structs didn't have identity last time I used C#, and that would be a very surprising thing to add." — a client-side JS framework author

That error landed next to the article's AI-generated diagrams, and a game-engine developer drew the obvious inference:

"Footnote 6 'How is this different from struct in C#' is inaccurate. Since the article is littered with AI-generated images, I assume the writing, or at least the research, is littered with hallucinations?" — a commenter who flagged the credibility knock-on

The AI tooling left a fingerprint inside the article itself: one image caption shipped as a raw LLM placeholder — [IMAGE: the same Point[] array in two variants…] — which a reader noted had "crashed your image generation post processing."

The catch that worries the people who'll use it

Underneath the language wars, engineers flagged a real semantic landmine. Flattened data must be read and written atomically or it can "tear" under concurrent access — so the flattening silently falls back to heap allocation when a value is too big for the platform's atomic write. One reader distilled the unease:

"'plus a null flag' is going to be the GIL of the JVM." — a commenter on the cost hidden in the null bit

The accomplishment is real: a value type that still looks like Java, after a design process long enough to become its own community in-joke. But "codes like a class, works like an int" already has an asterisk — an int is never null, and these can be. The fight over whether the rest ever ships has merely changed its slogan.