After more than a decade of development, Project Valhalla is finally entering the JDK mainline. JEP 401 (Value Classes and Objects) will be integrated into OpenJDK targeting JDK 28 (March 2027) as a preview feature.

This is not a small update. The pull request adds 197,000+ lines of code across 1,816 changed files. Oracle's Lois Foltan described it as an "extremely large change" — and that might be an understatement.

Here's what's changing, why it matters, and what it means for everyday Java developers.

The Problem Valhalla Solves

Java has lived with a fundamental asymmetry since day one:

• Primitive types (int, char, byte, double) are stored by value — fast, compact, no object overhead
• Everything else is a reference type — stored as heap pointers with object identity, headers, and dereferencing costs

This means every LocalDate, every Optional, every Integer wrapper carries the full weight of object identity — even when you don't need it.

The Identity Trap

Consider this code:

Integer a = 100;
Integer b = 100;
System.out.println(a == b);  // true — cached!

Integer c = 200;
Integer d = 200;
System.out.println(c == d);  // false — not cached!

Java caches Integer instances for values below 128, so == sometimes works. And sometimes it doesn't. This is what JEP 401's spec calls "unwanted complexity" — a polite way of saying it's a trap that has bitten every Java developer at least once.

Or take LocalDate:

LocalDate d1 = LocalDate.of(2026, 6, 15);
LocalDate d2 = LocalDate.of(2026, 6, 15);
System.out.println(d1 == d2);     // false — different references
System.out.println(d1.equals(d2)); // true — same values

Two identical dates compare as false with == because they live at different memory addresses. You must use .equals(). It works, but it's unnecessary cognitive overhead.

Enter Value Objects

JEP 401 introduces value objects — class instances that:

• Have no object identity (no memory address to compare)
• Are distinguished solely by their field values
• Allow the JVM to flatten them into memory — no headers, no pointers, no dereferencing

Think of it as giving Java developers the ability to create their own lightweight types that behave like primitives but carry the expressiveness of classes.

What This Unlocks

Memory efficiency: Value objects can be stored inline in arrays and fields without pointer overhead. An array of 1,000 LocalDate value objects takes roughly the space of the raw data — not 1,000 heap allocations plus header bytes.

Iteration speed: No dereferencing means cache-friendly memory layout. Iterating over value-type arrays is significantly faster because the CPU reads contiguous memory instead of chasing pointers.

Correct equality: Two value objects with the same fields are the same. No more == vs .equals() confusion for value types.

Breaking Changes — Yes, Really

Valhalla introduces deliberate breaking changes to Java. The most notable:

Code that synchronizes on Integer objects will throw an exception. Since value objects lack identity, you can't use them as monitor locks. Code like this breaks:

synchronized (Integer.valueOf(42)) {  // throws in JDK 28!
    // ...
}

This is a conscious design decision. Synchronizing on boxed primitives was always a bad practice — Valhalla makes it impossible.

Some JDK classes like Integer will migrate to value classes gradually. Migration of the full JDK library will happen incrementally across multiple releases.

The Timeline — Don't Hold Your Breath

Brian Goetz, Oracle's Java Language Architect, was blunt:

"Hoping for it to exit preview for 29 seems… optimistic."

That's the architect saying the next LTS won't have it as a stable feature. Developers should expect a long preview window — possibly multiple years.

This Is Just Part One

Goetz also noted:

"This is just the first part of Valhalla... the 'but they'll never deliver it' crowd will quickly switch gears into 'but they haven't delivered the most important part' soon enough."

JEP 401 removes identity from the equation. But full value semantics also requires giving up:

• Nullity — value objects can't be null
• Atomicity Safety Under Race (ASUR) — no synchronization guarantees

These are future JEPs. Valhalla is a multi-release journey, not a single feature drop.

Why It Took So Long

Project Valhalla has been in development so long that developers joke about reaching the actual mythological Valhalla first. The real reason for the delay, according to Goetz, is the challenge of "how to package it in the user model so that it doesn't fight with our own preconceived notions of object integrity and encapsulation."

In other words: Java's object model is 30 years old. Changing its foundational assumptions without breaking the entire ecosystem is genuinely hard. Every design decision ripples through generics, collections, serialization, reflection, and the entire JDK library.

What Developers Should Do Now

1. Audit code for synchronized on boxed primitives. This will break first. Search for synchronized (Integer, synchronized (Long, etc.

2. Start thinking in terms of identity vs. value. Which of your classes actually need identity? Most DTOs, value types, and records don't. They're perfect candidates for value classes once available.

3. Don't rush to adopt previews. Preview features can change between releases. Use them for experimentation, not production.

4. Watch for Vector API graduation. The Vector API has been stuck in incubation partly because it depends on Valhalla's underlying VM primitives. Once Valhalla lands, Vector API should finally exit incubation.

Comparison to Other Languages

Goetz himself compares the effort to C# structs. Many languages have already solved this problem:

• C#: struct value types since 2002
• Kotlin: value class (inline classes) since 1.5
• Swift: struct value types since launch
• Rust: Everything is value-based by default

Java is late to this party. But Java's constraint — backward compatibility with 30 years of enterprise code — is unique. No other language carries that burden at this scale.

The Bigger Picture

Valhalla isn't just about performance. It's about fixing a lie at the heart of Java's type system — the fiction that all objects need identity. They don't. A LocalDate is not a person. A Point is not a connection. Some things are just values.

By letting developers declare that intent explicitly, Valhalla gives the JVM permission to make the optimizations it always wanted to make but couldn't — because it couldn't be sure you weren't relying on identity.

That's worth waiting a decade for.

Sources:

• Java's Project Valhalla finally lands a preview in JDK 28 — Tim Anderson, The Register, 15 Jun 2026
• JEP 401: Value Classes and Objects — OpenJDK
• Project Valhalla — OpenJDK