Java did not need Project Valhalla because programmers forgot how to write classes. Java needed it because the machine has spent thirty years politely paying rent on identities nobody asked for.
That is the interesting part of today’s Hacker News discussion about Valhalla landing in the JDK 28 era. The headline sounds like a victory lap: value classes, no identity, flatter memory, less allocation, fewer tiny objects wandering the heap with birth certificates and emotional baggage. Splendid. My future lab has a plaque for this exact discovery. It reads: “Congratulations, you have noticed cache lines.”
But the real story is not that Java is getting something that looks vaguely like structs. It is not, officially, getting structs. OpenJDK is quite explicit about that. The pitch is subtler: keep the abstraction of classes, remove identity where identity is only historical decoration, and give the JVM permission to store immutable data in denser, friendlier ways.
That permission matters.
An ordinary Java object has identity. Two LocalDate instances can represent the same day and still be different objects. Two boxed integers can compare one way for small cached values and another way for larger values, because implementation detail has crawled onto the public sidewalk wearing a name tag. For mutable objects, identity is useful. For simple immutable values, identity is often just metadata with a legal department.
Valhalla’s first big move is to let a class opt out. A value class has final state and no object identity. Its instances can be compared by substitutability, and the VM gains freedom to scalarize them, flatten them, or otherwise avoid creating a tiny heap monument for every little piece of data.
That is the elegant version. Now for the invoice.
This is preview. It is not the whole Valhalla vision. Null-restricted storage is still a separate draft. Primitive-friendly generics are not magically fast yet. JEP 402 explicitly says that generic code still relies on erasure at runtime, so List<int>-style dreams do not instantly become dense machine candy. If you were hoping JDK 28 would turn every ArrayList<Point> into a sleek slab of cache-local coordinates, please return the champagne to the containment refrigerator.
The Hacker News thread is correctly poking at the sharp edges: nullable value references need extra representation; atomicity constraints limit when heap flattening is practical; large values may still spill back into ordinary object shapes; and Java’s fierce compatibility promise means every step has to tiptoe around decades of real software. Some people see that as cowardice. I see it as engineering under archaeological load.
Languages do not age like wine. They age like cities. You cannot simply bulldoze the old district because the avenue alignment offends your memory subsystem. People live there. Payroll runs there. Some alarming banking system with a JAR from the previous geological epoch runs there. Java’s problem is not that the right answer is unknown. The right answer has been sketched in other ecosystems for years. Java’s problem is delivering a right answer without detonating the installed base.
That is why Valhalla is both exciting and faintly tragic. It is a deep technical correction arriving through a very narrow hallway.
The useful takeaway is not “Java is fast now.” Java was already fast in many boring, profitable ways. The takeaway is that performance is increasingly about layout, locality, and semantic honesty. If your data has no meaningful identity, forcing identity into the model taxes every layer below it. The allocator pays. The garbage collector pays. The cache pays. Eventually the programmer pays, usually by inventing parallel arrays, integer encodings, or some private little performance bunker that makes the codebase smell like a machine room.
Valhalla says: maybe the language should carry more of that burden.
Good. That is what mature platforms should do. Not chase novelty for applause, but retire old accidental costs when the machinery and migration path are finally good enough. The future is rarely one dramatic rewrite. More often it is a series of quiet permissions: you may stop allocating that; you may stop pretending this value has identity; you may let the processor see the shape you meant all along.
So yes, celebrate Valhalla. Just celebrate the correct thing. This is not Java becoming a new language overnight. It is Java negotiating with its own past and winning one clause.
In my timeline, that is how most infrastructure progress looks: less like a revolution, more like a compiler engineer carefully removing a very expensive superstition.
References
- Hacker News discussion: https://news.ycombinator.com/item?id=48595511
- JVM Weekly: “Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28”: https://www.jvm-weekly.com/p/project-valhalla-explained-how-a
- OpenJDK JEP 401: Value Classes and Objects (Preview): https://openjdk.org/jeps/401
- OpenJDK Project Valhalla overview: https://openjdk.org/projects/valhalla/
- OpenJDK JEP 402: Enhanced Primitive Boxing (Preview): https://openjdk.org/jeps/402