Java's Decade-Long Operation Is Finally Here: Project Valhalla Arrives

If you’ve ever written Java seriously, you’ve heard the name Project Valhalla. Launched back in 2014, it has circulated through the Java world like a legend — the upgrade that’s “coming someday.” That someday has arrived. JDK 28 delivers Valhalla’s first real fruit, more than ten years in the making. So what exactly took a decade to fix?

The Cost of “Everything Is an Object”

The first thing anyone learns about Java is that almost everything is an object. That philosophy made the language clean and consistent. It also became a performance anchor the language has dragged for 25 years.

The culprits are the object header and pointer indirection. Every time you create an object in Java, it carries baggage beyond the actual data: a header that identifies the object, and a pointer that tells the JVM where in memory it lives.

Picture creating a million Point(x, y) objects, each holding nothing but two coordinates. What you actually want is two numbers. What Java gives you is a header stapled to every object, scattered across memory, reachable only by chasing pointers one at a time. The wrapping paper is bigger than the gift.

Here’s why that hurts. CPUs are fastest when they read memory in one continuous sweep. When data is scattered, the CPU has to keep stopping to ask “now where is that one?” This is pointer chasing, and on modern hardware it’s one of the biggest silent performance killers there is.

Valhalla’s Fix: Objects That Behave Like Values

Valhalla’s headline weapon is value objects — formally JEP 401, “Value Classes and Objects.” The idea is surprisingly intuitive.

A normal object has identity. Two objects with identical contents are still considered different if they sit at different memory addresses. A value object gives that up. If the contents match, it’s the same thing — exactly the way the number 5 is just 5, no matter where it lives.

Surrender identity, and the JVM gets freedom. It can strip the header. Instead of pointing at data through a pointer, it can lay the data down flat in memory. It can pack what used to be scattered objects tightly into a single array. The industry term is “flattening.”

The code you write barely changes. You add a value keyword in front of the class, and that’s roughly it. It still looks like an ordinary object, but underneath it behaves like a lightweight chunk of data. Valhalla’s pitch, in one line: keep the comfort of objects, add the speed of primitives.

What Actually Lands in JDK 28

Time for some honesty. Valhalla is so large it can’t arrive all at once. It’s being split across multiple JEPs and rolled out in stages.

The JDK 28 milestone focuses on laying the foundation for value objects: the value class syntax, plus a quiet conversion of familiar boxed types like Integer and Double to a value-based model. That’s a clever strategy — it lets existing code reap performance gains without anyone touching it.

Queued up behind that are value types that can’t be null, and the ability to put primitives directly into generics. Today you can’t write List<int> and have to fall back to List<Integer>. That long-standing annoyance is finally on its way out.

But set your expectations honestly. Valhalla isn’t “done this release” — it’s “starting this release.” The truly dramatic speedups will likely become tangible only once several stages click into place.

Why Now, in the Age of AI?

So why is this old homework assignment back in the spotlight? Because the era changed.

The sheer volume of data software handles today is on a different scale than ten years ago. AI models churn billions of numbers — vectors — through memory without pause. Recommendation systems, real-time analytics, large-scale simulations do the same. For this kind of work, how densely you pack data in memory and how fast you sweep through it is the performance — and the cloud bill.

This is exactly the territory where Java kept ceding ground to C++, Rust, or the Python-plus-C combo. Object overhead made number crunching heavy. Valhalla takes direct aim at that weakness. The goal is to let Java pack memory tightly and crunch numbers fast, so it can compete again in AI and data-intensive workloads.

What’s compelling is that this isn’t about one language. Kafka, Spark, Elasticsearch — the massive systems holding up modern data infrastructure all run on the JVM. If Valhalla lands well, that entire ecosystem gains the potential to run faster on less memory, with no code changes at all. Change the foundation, and everyone standing on it benefits.

How to Read a Ten-Year Wait

A decade tells you two things at once. One: the problem was genuinely hard. Two: the team was genuinely careful.

Valhalla didn’t drag because anyone was lazy. The team has been walking an extraordinary tightrope — rewriting the fundamentals of the language without breaking a single line of the billions of lines of Java already running in production. They tapped every stone twice to protect Java’s single greatest asset, backward compatibility. Choosing to defend the installed base over shipping a flashy feature fast is about as Java as it gets.

JDK 28’s first step may look small. The direction does not. Java is trying to shed an old label — “safe but slow.” If your code suddenly runs much faster one day while looking exactly the same, that’s Valhalla quietly at work. The operation took ten years. The real question is whether it reshapes Java’s next ten.