--- title: 8389219: Implement JEP 401: Value Objects (Preview) by... description: A major pull request has been opened against the OpenJDK repository implementing JEP 401: Value Objects (Preview) for the first time. The PR also bundles JEP... canonical: https://daily.dev/posts/8389219-implement-jep-401-value-objects-preview-by-mrsimms-pull-request-31120-openjdk-jdk-hghnkbn5r twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: 8389219: Implement JEP 401: Value Objects (Preview) by MrSimms · Pull Request #31120 · openjdk/jdk | daily.dev og:description: A major pull request has been opened against the OpenJDK repository implementing JEP 401: Value Objects (Preview) for the first time. The PR also bundles JEP... og:url: https://daily.dev/posts/8389219-implement-jep-401-value-objects-preview-by-mrsimms-pull-request-31120-openjdk-jdk-hghnkbn5r og:image: https://api.daily.dev/og/posts/hgHnkbn5r.png og:image:alt: 8389219: Implement JEP 401: Value Objects (Preview) by MrSimms · Pull Request #31120 · openjdk/jdk og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # 8389219: Implement JEP 401: Value Objects (Preview) by MrSimms · Pull Request #31120 · openjdk/jdk **[Hacker News](https://daily.dev/sources/hn)** · 2 min read · 0 upvotes · 0 comments ## Summary A major pull request has been opened against the OpenJDK repository implementing JEP 401: Value Objects (Preview) for the first time. The PR also bundles JEP 539: Strict Field Initialization in the JVM (Preview), since JEP 401 depends on it. Due to the enormous scope (2934 commits, dozens of contributors), the review is split across multiple sub-review PRs covering the compiler, JVM, and standard library changes. The master PR serves as the integration vehicle into jdk/master, with active development tracked in the valhalla/lworld branch. The PR has received required reviewer sign-offs and has been integrated. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 3 discussions and 153 comments across hackernews (as of 2026-07-31). **TL;DR:** The community is broadly enthusiastic about Project Valhalla's value objects finally landing in OpenJDK, praising the years of careful design and backward-compatibility work, while side debates rage about Java's cultural verbosity, Spring's bloat, and the 63-bit atomicity constraint. **Sentiment:** 65% positive · 25% mixed · 10% skeptical **The case for** - Value types finally address one of Java's biggest long-standing performance pitfalls, enabling better memory layout and flattening. - The Valhalla design is praised for its nuanced semantic model (identity, atomicity, nullability, tearability) rather than a simplistic object/value binary. - Java's approach of avoiding async/await in favor of virtual threads and structured concurrency is seen as a major win over C#. - Backward compatibility and long signposting of breaking changes are highlighted as strengths of the Java platform. - Modern Java (records, sealed interfaces, streams, virtual threads) is seen as a genuinely pleasant language when used with current features. - Lighter alternatives to Spring (Helidon, Quarkus) are maturing and offer a breath of fresh air for those who want to escape framework bloat. **The pushback** - The 63-bit atomicity constraint (tearability opt-in) is seen as a limitation compared to other languages that simply don't guarantee atomicity. - Java's cultural baggage — verbose enterprise patterns, over-engineered factory hierarchies — is seen as a persistent problem even if it's not a language flaw. - Spring's dominance in enterprise means BigCorp is slow to adopt lighter, more modern frameworks. - The build system situation (Maven/Gradle) is still considered poor by some. - This PR is only the first part of Valhalla; specialized generics and null constraints are still missing. - The large single-commit squash destroys incremental history, which some find concerning for an open-source project. **By community** - hackernews (positive): Commenters are largely excited about Valhalla landing, with substantive technical debate around atomicity/tearability, cultural verbosity, and comparisons to C# and C++, but the overall tone is celebratory and respectful of the engineering effort. **Hottest debate:** Whether the 63-bit atomicity constraint and opt-in tearability model is an elegant, safe-by-default design or an unnecessary complexity imposed by Java's historical misdesigns. **Open questions** - When will specialized/reified generics (JEP 218) land to complete the performance story for generic collections of value types? - Will String ever become a value class given its variable-length backing array? - Is there a 'caniuse' equivalent for CPU features like 128-bit atomic writes that would let OpenJDK relax the atomicity constraint? - Who is funding the Valhalla work — is it primarily Oracle employees? **Highlights** > I think you've misunderstood, because not only would this have been the right design if it had been in Java since day one as it's in line with the philosophy of the platform, it's also simpler than in other languages. The idea is that instead of controlling memory layout and referencing directly, you communicate your intent: do you care about this value's identity or not? Do you need atomicity or not? Do you need nullability or not? Once the intent is clear, the compiler is free to choose the most appropriate and efficient layout for the particular value at the particular use site. In other words, you say what semantics you're interested in rather than how to implement them at the lowest level. This opens up optimisation opportunities that are lost when the programmer directly controls the representation rather than the intent. E.g. in other languages you may say whether you want to pass some value by reference or by value. Here the compiler is free to say, well, if identity and nullability are not needed here, I can either pass by value or by reference, and I'll do whichever is more efficient. And by the way, your point about early misdesign (whether it applies here or not) also inverts the desired state. Every language makes decisions that will be suboptimal in the environment some time later, and Java certainly has its share (its mutability and nullability default; how it treats serialisation). Rust, for example, was first designed twenty years ago, and some of its fundamental decisions reflect the state of the world at that time (it went all-in on some C++ premises that seemed fine 20 years ago). But since important codebases often outlast the outdatendness of early language decisions (your OS and your browser are running some >30yo code and/or affected by >30yo design decisions), one of the things most important in a language isn't the decisions it makes early on - some will prove "wrong" while your codebase is still alive and kicking - but how well it adapts and evolves. So when you pick a language for an important project today, the language's current state will end up mattering less than how the language evolves in the future. The question asked isn't "will I like this decision today?" but "will I regret this decision ten years from now?" Java is one of the languages with the lowest "regret factor", possibly lowest of them all. > — [pron on hackernews](https://news.ycombinator.com/item?id=49123762) > What I love the most is the sheer amount of thought and philosophy put into Valhalla. It transcends the binary understanding of object vs value and actually defines 4 distinct buckets: 1: Classical Object 2: Object without identity 3: Atomic Value 4: Classical Value (Tearable) Each bucket has clearly defined performance characteristics and semantic constraints. So depending on the nature of your data, you can always get some benefit from values even if you couldn't go all the way. This is a work of art. > — [DarkNova6 on hackernews · 1 comments](https://news.ycombinator.com/item?id=49121260) > I've said this before but I'll say it again: The worst part of Java is Java programmers. For most of my career, I thought I hated Java, primarily because every piece of Java code I had ever worked with was overly verbose across a million different files to do things that would take like ten lines of code in any other language. Then I actually started looking at all the features for Java 8, 11, 17, and 21, and realized: NO! Java actually gives lots of really great tools and language features that allow you to write relatively pretty, terse, performant code. Record types help cut down on a lot of boilerplate stuff, the streams API allows for pretty work over lists, sealed interfaces mostly solve my itch for ADTs, virtual threads are genuinely pretty impressive bits of engineering, and for the stuff that isn't built in, Vert.x and Disruptor do a pretty good job filling in the gaps. Once I learned all that, I was kind of mad at people still writing code like it was 1999, but also started to enjoy writing Java. It helps that by this time I was already senior and staff level, meaning I was given much more leeway in how code was written (so the poor junior engineers are stuck/blessed dealing with my code using all the shiny new features). > — [tombert on hackernews · 2 comments](https://news.ycombinator.com/item?id=49123669) > What I do like about java is that when breaking changes must happen (and they do occasionally), they are almost always small and the java authors signpost it WELL in advance of making the break. For example, this is technically legal in Java and will probably work today. Both foo and bar will synchronize on the same referenced object due to the integer cache. This is something that will break when value types land for real. void foo() { Integer i = 1; synchronized(i) { doEvil(); } } void bar() { Integer i = 1; synchronized(i) { doEvil(); } } > — [cogman10 on hackernews · 1 comments](https://news.ycombinator.com/item?id=49122032) > java the language is amazing the problem with it is entirely cultural. why is `IStatusChangeEntityCreationManagerFactory` everywhere? and why are the frameworks so huge and all encompassing? i think batteries included rails-style frameworks are great, but when i wrote Java, it didn't feel like rails at all none of these are language problems > — [merlindru on hackernews · 6 comments](https://news.ycombinator.com/item?id=49120797) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49119063) · 91 points · 153 comments - [hackernews](https://news.ycombinator.com/item?id=48097761) · 4 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=48321526) · 3 points · 0 comments ## Similar posts on daily.dev - [JEP 401: Value Objects \(Preview\)](https://daily.dev/posts/jep-401-value-objects-preview--1rxfjujqr) · Inside Java · 2 upvotes · 0 comments - [Java’s biggest language change in a decade is finally landing. It took 197,000 lines of code.](https://daily.dev/posts/java-s-biggest-language-change-in-a-decade-is-finally-landing-it-took-197-000-lines-of-code--8eeespmnb) · The Next Web · 39 upvotes · 1 comments - [JEP 539: Strict Field Initialization in the JVM \(Preview\)](https://daily.dev/posts/jep-539-strict-field-initialization-in-the-jvm-preview--oulwj2mlq) · Inside Java · 0 upvotes · 0 comments --- Tags: [#java](https://daily.dev/tags/java), [#jvm](https://daily.dev/tags/jvm) [View this post on daily.dev](https://daily.dev/posts/8389219-implement-jep-401-value-objects-preview-by-mrsimms-pull-request-31120-openjdk-jdk-hghnkbn5r) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"8389219: Implement JEP 401: Value Objects (Preview) by MrSimms · Pull Request #31120 · openjdk/jdk","url":"https://daily.dev/posts/8389219-implement-jep-401-value-objects-preview-by-mrsimms-pull-request-31120-openjdk-jdk-hghnkbn5r","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/8389219-implement-jep-401-value-objects-preview-by-mrsimms-pull-request-31120-openjdk-jdk-hghnkbn5r"},"datePublished":"2026-07-31T07:06:54.169Z","dateModified":"2026-07-31T15:24:18.798Z","description":"A major pull request has been opened against the OpenJDK repository implementing JEP 401: Value Objects (Preview) for the first time. The PR also bundles JEP...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/99a2c59e9dc9b9b906023e55888a85a2?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/99a2c59e9dc9b9b906023e55888a85a2?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/8389219-implement-jep-401-value-objects-preview-by-mrsimms-pull-request-31120-openjdk-jdk-hghnkbn5r","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"java,jvm","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"8389219: Implement JEP 401: Value Objects (Preview) by MrSimms · Pull Request #31120 · openjdk/jdk"}]} ```