Project Valhalla in JDK 28: What Value Classes Actually Change

작성자

카테고리:

← 피드로
DEV Community · Dev Encyclopedia · 2026-06-27 개발(SW)
Cover image for Project Valhalla in JDK 28: What Value Classes Actually Change

Dev Encyclopedia

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 [email protected]. 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

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다