HN Debrief

Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

  • Programming
  • Infrastructure
  • Developer Tools
  • Open Source

The article tries to explain Project Valhalla for general Java developers. The core claim is that JDK 28 will preview value classes, which are Java classes without identity that can be stored more like primitives. That matters because ordinary Java objects carry headers, pointer indirection, and heap churn. Value classes are meant to let the JVM flatten data, cut memory overhead, and eventually make arrays and generic collections of small immutable values much denser and faster.

If you run large Java systems, Valhalla is now real enough to track, but not real enough to bank product plans on yet. The immediate practical payoff looks narrow until null-restriction and generic specialization land, so teams should watch JDK 28 previews and library migration plans rather than expect instant speedups from existing code.

Discussion mood

Mixed but engaged. People are impressed that Valhalla is finally landing after years of delay, yet a lot of the mood is frustration that the first deliverable looks narrower than the headline suggests and anger that the article explaining it appears partially AI-generated and error-prone.

Key insights

  1. 01

    Why Java dropped two projections

    The abandoned design was not mainly about null safety. It was about whether every type should expose separate reference and value forms, like a generalized `Integer` and `int`. OpenJDK commenters said that model made the language heavier, so the current plan keeps one source-level type, removes identity from value classes, and lets the compiler and runtime pick layout based on context and nullability. That framing makes Valhalla less about syntax sugar and more about decoupling semantics from storage.

    Expect future Java APIs to describe identity, nullability, and tearability separately instead of baking representation into type names. If you design JVM libraries, avoid assuming today’s wrapper-versus-primitive split is the long-term model.

  2. 02

    Backward compatibility is the whole project

    What makes Valhalla hard is not inventing value types. It is making old libraries, old binaries, autoboxing, and generic APIs keep working without recompilation. Several commenters pointed out that Java wants existing classes like `Optional` and wrapper types to become better value-like citizens without forcing everyone onto brand-new replacement types. That constraint explains years of design churn far better than any claim that the Java team only just discovered structs.

    Judge Valhalla by migration behavior, not by whether another language had structs first. The practical question for your codebase is whether libraries you already depend on can adopt these semantics without API forks.

      Attribution:
    • Someone #1
    • pjmlp #1 #2
    • mike_hearn #1
    • gf000 #1
  3. 03

    First-wave performance wins are limited

    The early preview does not unlock the headline use case of dense generic collections, and flattening on the heap is still boxed in by nullability and tearing rules. Commenters argued that until null-restricted types or explicit tearable semantics arrive, many value classes larger than a machine-word-sized atomic write will not get the dramatic packed-array layout people expect. The immediate wins look real for some wrappers and stack-local optimization, but not for every domain object you wish were a struct.

    Do not promise broad memory or throughput gains from Valhalla in 2028-era roadmaps. Benchmark specific hot paths and watch for follow-on JEPs before restructuring data models around assumed flattening.

      Attribution:
    • tsimionescu #1
    • boroboro4 #1
    • cogman10 #1
    • moomin #1
  4. 04

    Wrapper identity changes are a real compatibility edge

    Turning boxed numerics like `Integer` into identity-free value classes cleans up some long-standing weirdness around `==`, caching, and autoboxing. It also creates a genuine source of breakage for code that relied on wrapper identity, synchronization, or old comparison behavior. Some commenters dismissed that code as already broken in spirit, but the point stands that Valhalla is not completely compatibility-neutral even when it tries hard to be.

    Audit any Java code that synchronizes on wrapper objects or relies on `==` with boxed values. Those patterns were brittle already, and Valhalla makes them actively unsafe.

      Attribution:
    • pron #1
    • tsimionescu #1
    • anabab #1
    • lacerrr #1
  5. 05

    Null-restricted types are still unsettled

    The draft syntax around `!` prompted complaints that Java is heading toward noisy per-variable null markers instead of sane defaults. OpenJDK replies said the draft already hints at broader context-wide null restriction later, but that work is still future-facing and not committed in the same way as value classes themselves. That leaves a gap between the semantic model Valhalla wants and the ergonomics many developers actually care about.

    If null safety is your primary reason for caring about Valhalla, keep expectations low for the first release. Follow the null-restriction JEP work separately, because that is where everyday developer experience will be decided.

      Attribution:
    • stickfigure #1
    • pron #1
    • rf15 #1
  6. 06

    Modern Java and deployed Java are different worlds

    One useful reality check was that Java’s reputation problem comes from two truths at once. The platform in 2026 has virtual threads, records, sealed types, and aggressive runtime work. A lot of actual enterprise code is still stuck on Java 8 or older architecture decisions, so critics and defenders are often talking about different Java eras. That mismatch explains why comments about the language can sound wildly out of sync.

    When evaluating JVM bets, separate platform capability from fleet reality. Your migration cost is driven less by what Java supports today than by how far your production estate is from current LTS releases.

      Attribution:
    • devin #1
    • mands #1
    • 63 #1

Against the grain

  1. 01

    The article still taught the right thing

    A few readers argued that the pile-on over AI provenance was missing the bigger point. They found the explainer informative enough to understand Valhalla’s shape and thought the constant policing of AI style was becoming noise in its own right. That view pushes back on the idea that suspicious writing style automatically invalidates technical content.

    Do not discard technical material purely on style tells. Verify core claims against primary docs, but separate presentation flaws from whether the underlying explanation helped you orient.

      Attribution:
    • munksbeer #1
    • 725686 #1
  2. 02

    Oracle improved Java more than Sun did late

    The common story that Oracle smothered Java got hard pushback from people who have watched the platform closely. They argued Java stagnated in Sun’s final years, then accelerated under Oracle with OpenJDK as the reference implementation, more frequent releases, and major runtime work like Loom and newer garbage collectors. That does not make every Oracle decision beloved, but it undercuts the lazy narrative that current Java progress happened despite Oracle rather than under it.

    If your view of Java stewardship is frozen around the Sun acquisition backlash, update it before making platform calls. Recent release cadence and runtime improvements matter more than decade-old corporate reputation.

      Attribution:
    • gf000 #1
    • homebrewer #1
    • pron #1
  3. 03

    This is not just Java copying C# structs

    Some comments rejected the easy comparison to `.NET` structs. The argument was that shipping structs in a greenfield runtime is one problem, while retrofitting identity-free values into Java’s existing primitive, boxing, and erased-generic world is another. Even if the end-user feature rhymes with C#, the compatibility and migration engineering is where the novelty sits.

    When comparing language features across ecosystems, compare the migration constraints too. A similar surface feature can hide very different platform risks and implementation tradeoffs.

      Attribution:
    • rf15 #1
    • misja111 #1
    • gf000 #1
    • coldtea #1

In plain english

atomic write ↩
A memory write that appears to happen all at once, so other threads never observe a half-written value.
autoboxing ↩
Java’s automatic conversion between primitives like `int` and wrapper objects like `Integer`.
boxing ↩
Wrapping a primitive-like value in an object so it can be used where the language or runtime expects an object reference.
flattening ↩
Storing the fields of values directly inside an array or containing object instead of storing pointers to separate heap objects.
generic specialization ↩
An implementation technique where generic containers get type-specific layouts or code so they can store values efficiently without boxing.
heap ↩
The area of memory where a runtime allocates long-lived objects dynamically while a program runs.
identity ↩
The property that lets two objects be distinguished as separate instances even if all their fields are equal.
JDK ↩
Java Development Kit, the standard distribution of tools and runtime used to build and run Java programs.
JEP ↩
JDK Enhancement Proposal, the formal design document process used for major Java platform changes.
JVM ↩
Java Virtual Machine, the runtime that executes Java bytecode and manages memory, threading, and garbage collection.
OpenJDK ↩
The open-source reference implementation of the Java platform where new Java language and JVM features are developed.
Project Valhalla ↩
An OpenJDK project to add identity-free value classes and related runtime changes so Java can represent some data more compactly and efficiently.
tearing ↩
A concurrency problem where one thread reads a partially updated multi-word value because the write was not atomic.
virtual threads ↩
Very lightweight Java threads introduced by Project Loom so applications can run large numbers of concurrent tasks with simpler code.

Reference links

Primary Java specs and proposals

Article provenance and AI-style references

Comparative language references

Historical and hardware context