--- title: Value Classes Still Need Compiler Sympathy | daily.dev description: An in-depth technical exploration of Java's value classes (Project Valhalla, JEP 401, preview in JDK 28) shows that value classes are not a guaranteed... canonical: https://daily.dev/posts/value-classes-still-need-compiler-sympathy-6gmnyemca twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Value Classes Still Need Compiler Sympathy | daily.dev og:description: An in-depth technical exploration of Java's value classes (Project Valhalla, JEP 401, preview in JDK 28) shows that value classes are not a guaranteed... og:url: https://daily.dev/posts/value-classes-still-need-compiler-sympathy-6gmnyemca og:image: https://api.daily.dev/og/posts/6GMNYEMCa.png og:image:alt: Value Classes Still Need Compiler Sympathy 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. # Value Classes Still Need Compiler Sympathy **[Inside Java](https://daily.dev/sources/inside_java)** · 13 min read · 0 upvotes · 0 comments ## Summary An in-depth technical exploration of Java's value classes (Project Valhalla, JEP 401, preview in JDK 28) shows that value classes are not a guaranteed performance floor above ordinary classes. Through three examples involving JEP 539 strict field initialization, C2 scalarization of a loop, and a type-erasure case with megamorphic interface calls, the piece demonstrates how immutability enables flattening, how identity removal enables allocation elimination, and how generic bridge methods can force materialization and reintroduce allocations. A real-world regression reported by a valhalla-dev mailing list user is diagnosed and fixed by explicitly redeclaring a typed interface method, cutting per-call allocation from 192 bytes to zero. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is JEP 401 in JDK 28 and what does it enable? JEP 401 integrates value classes as a preview feature in JDK 28, a major milestone of Project Valhalla. Value classes give up object identity, letting the JVM freely choose flattened or scalarized representations instead of heap references, enabling optimizations like avoiding pointer chasing and eliminating allocations, while also communicating clearer semantics to other programmers. _Developers evaluating JDK 28 preview features can track Valhalla's value class rollout and gotchas on daily.dev._ ### Why did converting records to value records make a Java program slower instead of faster? Because of generic type erasure combined with megamorphic interface dispatch. When an interface method is inherited through a generic type parameter erased to Object, the JVM must invoke it as Object apply(Object), forcing scalarized value objects to be materialized into real heap objects at every call and re-scalarized inside a bridge method. In one reported case this cost 192 bytes per call; explicitly redeclaring the typed method signature on the interface eliminated the allocation entirely. _Anyone debugging unexpected allocation regressions after adopting value classes can find concrete fixes like this through daily.dev._ ### Why can't the JVM flatten a mutable field containing a large value type like a 32-byte record? Because flattening a large value requires writing its components individually, and the Java Memory Model forbids other threads from observing a torn value assembled from parts of two different assignments. JEP 539 (Strict Field Initialization) lets the JVM flatten a final field non-atomically since it is never updated after initialization, but a mutable field holding a value too large for an atomic update must instead use a reference layout to guarantee tear-free assignment. _Engineers reasoning about JVM memory layout and concurrency guarantees can dig into details like this via daily.dev._ ## Similar posts on daily.dev - [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 - [Valhalla, Now\!](https://daily.dev/posts/valhalla-now--aua4ibtem) · nipafx \(Nicolai Parlog\) · 0 upvotes · 0 comments - [Optimizing Java Class Metadata in Project Valhalla – Inside.java](https://daily.dev/posts/optimizing-java-class-metadata-in-project-valhalla-inside-java-tsiljbslw) · Inside Java · 6 upvotes · 0 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#java](https://daily.dev/tags/java) [View this post on daily.dev](https://daily.dev/posts/value-classes-still-need-compiler-sympathy-6gmnyemca) ```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":"Value Classes Still Need Compiler Sympathy","url":"https://daily.dev/posts/value-classes-still-need-compiler-sympathy-6gmnyemca","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/value-classes-still-need-compiler-sympathy-6gmnyemca"},"datePublished":"2026-08-24T16:49:02.022Z","dateModified":"2026-09-14T09:13:59.073Z","description":"An in-depth technical exploration of Java's value classes (Project Valhalla, JEP 401, preview in JDK 28) shows that value classes are not a guaranteed...","image":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","thumbnailUrl":"https://media.daily.dev/image/upload/s--HRgLpUt6--/f_auto/v1722860399/public/Placeholder%2003","isAccessibleForFree":true,"articleSection":"Inside Java","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":"Inside Java","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/de5992d95f374790bdfd2ae03a16f6e3","url":"https://daily.dev/sources/inside_java"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/value-classes-still-need-compiler-sympathy-6gmnyemca","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"performance,java","timeRequired":"PT13M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Inside Java","item":"https://daily.dev/sources/inside_java"},{"@type":"ListItem","position":3,"name":"Value Classes Still Need Compiler Sympathy"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/value-classes-still-need-compiler-sympathy-6gmnyemca#faq","mainEntity":[{"@type":"Question","name":"What is JEP 401 in JDK 28 and what does it enable?","acceptedAnswer":{"@type":"Answer","text":"JEP 401 integrates value classes as a preview feature in JDK 28, a major milestone of Project Valhalla. Value classes give up object identity, letting the JVM freely choose flattened or scalarized representations instead of heap references, enabling optimizations like avoiding pointer chasing and eliminating allocations, while also communicating clearer semantics to other programmers. Developers evaluating JDK 28 preview features can track Valhalla's value class rollout and gotchas on daily.dev."}},{"@type":"Question","name":"Why did converting records to value records make a Java program slower instead of faster?","acceptedAnswer":{"@type":"Answer","text":"Because of generic type erasure combined with megamorphic interface dispatch. When an interface method is inherited through a generic type parameter erased to Object, the JVM must invoke it as Object apply(Object), forcing scalarized value objects to be materialized into real heap objects at every call and re-scalarized inside a bridge method. In one reported case this cost 192 bytes per call; explicitly redeclaring the typed method signature on the interface eliminated the allocation entirely. Anyone debugging unexpected allocation regressions after adopting value classes can find concrete fixes like this through daily.dev."}},{"@type":"Question","name":"Why can't the JVM flatten a mutable field containing a large value type like a 32-byte record?","acceptedAnswer":{"@type":"Answer","text":"Because flattening a large value requires writing its components individually, and the Java Memory Model forbids other threads from observing a torn value assembled from parts of two different assignments. JEP 539 (Strict Field Initialization) lets the JVM flatten a final field non-atomically since it is never updated after initialization, but a mutable field holding a value too large for an atomic update must instead use a reference layout to guarantee tear-free assignment. Engineers reasoning about JVM memory layout and concurrency guarantees can dig into details like this via daily.dev."}}]} ```