Project Valhalla, one of OpenJDK's most ambitious efforts, aims to align JVM memory layout with modern hardware cost models by introducing value classes - composite data types without identity, avoiding object header overhead. As of JDK 28 EA, 30 JDK classes (wrapper types, Optional, java.time classes) have been migrated to value types behind --enable-preview. The first Valhalla pieces have now landed on OpenJDK main as preview features, a major milestone opening broader testing. Early tooling gaps are noted: Maven 3.9.9 works with JDK 28 EA, Gradle 9.7.0 does not yet support JDKs beyond 26, Kotlin's kapt annotation processor fails due to javac internals access changes, Kotlin doesn't support the -ea suffix on version numbers, and ASM lacks Java 28 support though work is underway.
Questions this post answers
What is Project Valhalla and why does it change how Java objects work?
Project Valhalla introduces value classes, a new kind of Java data that behaves like composite or user-defined types but lacks object identity, similar to primitives. This lets such objects skip the overhead of an object header, since the JVM doesn't need to track identity for equal field values. Value classes must be final so method targets are known at class loading time. Developers tracking how Valhalla reshapes JVM memory layout can follow the rollout on daily.dev.
Which JDK classes have been migrated to value types in JDK 28 EA?
As of JDK 28 EA, 30 classes have been migrated to value types when the --enable-preview flag is set. These include the wrapper classes Integer, Long, Float, Double, Byte, Short, Character, and Boolean, plus Optional and its primitive variants, and java.time classes LocalDate, LocalTime, LocalDateTime, ZonedDateTime, and Duration. Anyone planning a JDK 28 upgrade can keep tabs on Valhalla's value-type migration through daily.dev.
Does Gradle or Kotlin's kapt work with JDK 28 EA builds that include Valhalla value types?
No, Gradle 9.7.0 does not yet support JDKs beyond version 26, so Gradle projects will not build on JDK 28 EA. Kotlin projects using the kapt annotation processor also fail, because each JDK release changes access to javac internals that kapt depends on; Kotlin 2.5.0 is expected to address this with a mode that avoids needing internals access. Teams weighing an early JDK 28 test run can check tooling compatibility notes like this on daily.dev.