JEP 401 Value Objects (Preview) merged into OpenJDK master
Overview
JEP 401 Value Objects (Preview) and JEP 539 Strict Field Initialization have been merged into the OpenJDK master branch.
The pull request #31120 integrated 2,934 commits with 208,011 additions and 13,161 deletions, implementing the first preview of JEP 401 together with the dependent JEP 539. The change was ready for integration on July 31, 2026 after resolving merge conflicts and receiving the required approvals. All resulting code should be developed further in the valhalla/lworld repository, which is synchronized with jdk/master on weekly tags.
Language Implementation
The Java language now permits declaration of value classes that define immutable, identity‑free types.
This change corresponds to the sub‑review JDK‑8317277 (Java language implementation of value objects). Value classes can be used as type arguments for generic types such as List<T> and Comparable<T>. As one commenter noted, "Generic types such as List
JVM Implementation
The JVM has been updated to allocate value objects without traditional object headers and to enforce strict field initialization as previewed by JEP 539. This work is tracked in sub‑review JDK‑8317278 (JVM implementation of value objects). The JVM now treats value objects as inline types, removing object identity and associated header overhead. One commentator questioned the implications: "If I understand this correctly then Integer becomes a value class and every instance of it loses its object identity. I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me." Another asked about data limits: "What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability?" These questions reflect the preview nature of the feature.
Standard Library Updates
Core library adjustments accommodate value objects while preserving existing reference types for classes such as String. The sub‑review JDK‑8317279 (Standard library implementation of value objects) updated the JDK to work with value types. A community member observed the remaining distinction: "Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability." Meanwhile, another praised the progress: "Modern Java friggen rocks. I honestly cannot understand why you would use anything but the OG these days!"
Relationship with JEP 539
JEP 401 depends on JEP 539’s preview of strict field initialization to guarantee that value object fields are fully initialized before use. The pull request description explicitly states that JEP 539 was implemented in the same code base because JEP 401 relies on strict field initialization. No further commentary on this dependency appears in the source material.
Community Reaction
Hacker News commentators welcomed the merge as a performance milestone while discussing its scope and relation to the wider Valhalla effort.
I feel lonely in that: I mostly love Java as a language. The lack of value types is the biggest impediment to certain types of performance. I am really looking forward to this evolution of the language. – @timmg I think it is important to understand what this does and does not cover. This is “only the first part of Valhalla”. See e.g. a good summary at https://www.jvm-weekly.com/p/project-valhalla-explained-how-... – @mormegil I'm always amazed by how much thinking and work the Java leads put in rolling out changes that move the language forward, but make it backward compatible as much as possible. – @ludovicianul Modern Java friggen rocks. I honestly cannot understand why you would use anything but the OG these days! – @exabrial It's really nice to see movement here finally. Lack of value types has been one of the biggest performance pitfalls in Java for decades at this point – @swiftcoder It's pretty interesting that while both languages still receive new features, Java seems to stay ahead of - Java has long had a modern replacement for Date, while JavaScript's recently standardized Temporal API still isn't supported in Safari. - Java has switch expressions, while JavaScript, despite its Scheme influence, does not. - And now Java is getting value objects, while JavaScript's equivalent tuples & records proposal has been withdrawn. – @sheept Generic types such as List
and Comparable can be instantiated with value classes as the type arguments. JEP 218, Generics over Primitive Types (with revisions), will allow generic classes and methods to specialize field, array, and local variable layouts when parameterized by value class types. Ok now this is cool! JVM needs more ways to use compile time known value sizes for better memory allocation and optimizations. – @ivanjermakov If I understand this correctly then Integer becomes a value class and every instance of it loses its object identity. I do not have a lot of knowledge about the details but from the outset it seems like a rather bold move to me. – @weinzierl Previous HN discussion on project Valhalla: https://news.ycombinator.com/item?id=48595511 – @kuhsaft I keep forgetting the reasoning for this part of the design - why is the value semantics baked in the declaration site and not at the use site? Why does the class author have to declare it as a value type? I know this has been rehashed before many times by Brian but I keep forgetting the reasoning. – @swaranga That's great, even though specialized generics are still missing. I think these improvements will be especially beneficial for Scala, because it is such a powerful language, but abstracting on the JVM comes at a heavy price. – @pregnenolone 2934 commits OMG... huge work. – @germandiago Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability – @parallax_error What's the latest status? Is it still limited to 63-bits of data plus 1 bit for nullability? – @HexDecOctBin The MR is closed This is it https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842... – @ligarota How much of Valhalla is this? 50% of it? 90% of it? – @whytevuhuni Bookmarked for later – @hn4yci687u