DEV Community

Cover image for Java Might Finally Kill a Decade-Old Pain Point: Value Objects Are Coming to JDK 28
Ashish Sharda
Ashish Sharda

Posted on

Java Might Finally Kill a Decade-Old Pain Point: Value Objects Are Coming to JDK 28

Last week, two JEPs quietly moved from "candidate" to "proposed to target" for JDK 28. One of them has been eleven years in the making.

The headline: Value Objects (JEP 401)

Project Valhalla's Value Objects proposal just got re-elevated — its original draft goes all the way back to August 2020, and the underlying idea predates even that. The pitch is simple to state and hard to build: objects that only contain final fields, have no identity, and are distinguished purely by the values of their fields.

If that sounds like "just use a record," here's the difference. Records give you a clean data-carrier syntax, but under the hood they're still regular objects with identity — heap-allocated, == compares references, and the JVM can't flatten them into arrays or inline them the way it does primitives. Value objects remove identity entirely. No more accidental identity comparisons where you meant to compare data. No more object-header overhead for a wrapper around a single long. The JVM gets real permission to lay these out efficiently, which is the whole point of Valhalla — closing the "primitives are fast, objects are slow" gap that's shaped Java performance work for two decades.

The review is set to conclude July 30, 2026.

My take: this is the kind of change that quietly rewrites default advice. Once value objects ship, "should this be a class or a record or a value class" becomes a real design question for anyone writing DTOs, wrapper types, or numeric-adjacent domain objects (money, coordinates, IDs). I'd bet within a year of GA, style guides start recommending value classes as the default for anything that's pure data with no need for identity.

Also worth knowing: Simple JSON API (JEP 540, Incubator)

The other JEP from the same batch: a built-in, standard API for parsing and writing JSON — no Jackson, no Gson, no third-party dependency required for the common case. It's an incubator module, so don't rip out your existing JSON stack yet, but it's a signal. A huge share of real-world Java code exists just to shuttle JSON in and out of objects, and Java has never had an opinion on how to do it. That's changing.

Smaller but notable: JEP 541 deprecates macOS/x64

Following the same pattern as the Windows 32-bit x86 deprecation, Apple's move away from Intel silicon is now reflected upstream: the macOS/x64 port is being deprecated for removal. If you're still building or testing on Intel Macs, this is your heads-up to start planning the migration off that architecture.

Where this leaves us

Two JEPs, one incubator API, and a decade-old performance promise finally getting a real target release. JDK 28 is shaping up to be one of those releases where the changes aren't flashy syntax sugar — they're structural. Value objects in particular are worth watching closely between now and the July 30 review conclusion.

What's your take — does "value class vs. record vs. regular class" become a real decision point for your codebase once this lands, or is this mostly a JVM-internals win that won't change how most of us write code day to day?

Top comments (0)