DEV Community

Cover image for Project Valhalla in JDK 28: What Value Classes Actually Change
Dev Encyclopedia
Dev Encyclopedia

Posted on • Originally published at devencyclopedia.com

Project Valhalla in JDK 28: What Value Classes Actually Change

#java #jvm #programming #performance

Project Valhalla has been Java's most anticipated, slowest arriving feature for over a decade. On June 15, 2026, Oracle engineer Lois Foltan confirmed JEP 401 (Value Classes and Objects) is integrating into OpenJDK mainline, targeting a preview in JDK 28.

The scale is significant: 197,000 lines across 1,816 files. Oracle described it as the biggest change to Java's object model since the language's creation in 1995.

If you have heard "Valhalla" mentioned for years without anything shipping, this is the moment something concrete actually lands.

The problem it solves

In Java, everything except eight primitive types is a reference type. Write Point p = new Point(1, 2) and p is not a point, it is a pointer to an object on the heap. For a million-element array of Point objects, you get a million scattered pointers, each requiring a separate dereference.

Valhalla's goal, in Brian Goetz's words, is to let code "look like a class, work like an int."

How to try it

Early access builds are at jdk.java.net/valhalla.

javac --enable-preview --release 28 Point.java
java --enable-preview Point
Enter fullscreen mode Exit fullscreen mode

A minimal value class:

value class Point {
    int x;
    int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}
Enter fullscreen mode Exit fullscreen mode

Or the same thing as a value record, usually the better choice for a pure data tuple:

value record Point(int x, int y) {}
Enter fullscreen mode Exit fullscreen mode

The detail that will surprise you

Value classes can still be null.

Point p = null; // perfectly legal in JDK 28's value class model
Enter fullscreen mode Exit fullscreen mode

"Value type" intuitively sounds like "works like a primitive, so no null," but that is a separate, later JEP. In this preview, value classes are still reference types under the hood. They have given up identity, not nullability.

The breaking change to audit for

java.lang.Integer and other wrapper classes are migrating to value classes under this preview. That means synchronized(someInteger) now throws an exception.

If you have code anywhere doing synchronized on wrapper types, a pattern most developers do not realize they rely on, this preview surfaces it immediately. Search your codebase before opting in.

What scalarization actually does

When the JIT can prove the concrete type at a call site, it breaks the value object into its constituent fields at the machine code level. Instead of passing a pointer to a Color, it passes three bytes plus a null flag directly. No allocation. Nothing for the garbage collector to track.

Heap flattening handles arrays: instead of pointers to scattered objects, the array stores the actual data inline and contiguously, with real field names and real validation.

What is NOT in JDK 28

  • Null restricted (non nullable) types, a separate JEP
  • Full specialized generics (List<int>)
  • 128 bit value encodings
  • Vector API, still in incubation

JDK 28 is also not an LTS release. The next LTS is expected to be JDK 29 in September 2027, and Goetz has called hoping for Valhalla to fully exit preview by then "optimistic."

Should you use it now?

It is a preview feature, disabled by default, and the syntax can still change. If you work on performance-critical Java fighting object overhead with hand-rolled primitive encodings, it is worth experimenting with now and reporting findings to valhalla-dev@openjdk.org. It is not yet something to migrate production code onto.

Full breakdown, including the value class vs record comparison table and the type category breakdown after JEP 401:

https://devencyclopedia.com/blog/project-valhalla-jdk-28-value-classes

Top comments (0)