How OOP will be Changed by Java?

[paserbyp]

Java developers have spent decades working with a basic assumption about objects: every object has its own identity. Now, OpenJDK developers are preparing to loosen that rule with JDK 28.

OpenJDK's long-running Project Valhalla(https://openjdk.org/projects/valhalla) has integrated JEP 401, Value Classes and Objects(https://openjdk.org/jeps/401), into JDK 28, where the feature will appear in preview. The change introduces a new category of Java object that has fields and methods like other objects but does not have traditional object identity. The Project Valhalla documentation(https://github.com/openjdk/valhalla-docs/blob/main/site/_index.md?utm_source=chatgpt.com) says the feature is now integrated and available for developers to try in early-access JDK 28 builds.

That may sound like an obscure change to Java's type system. In practice, it addresses a longstanding tension between the programming model developers get from classes and the efficiency associated with primitive values. The idea is that some things represented as objects do not actually need to be distinguished by identity.

A date, for example, is normally interesting because of the date it represents, not because it occupies one particular location in memory. Two objects representing Jan. 23, 1996, can be considered interchangeable for many purposes. Java has historically treated them as separate objects anyway. JEP 401 gives developers a way to tell Java when that distinction does not matter.

Under JEP 401, developers will be able to declare a class using the value modifier. Instances of those classes are value objects.
Value classes are intended for immutable domain values whose instances can be treated as interchangeable when their fields contain the same values. Their instance fields are implicitly final, and a concrete value class is implicitly final as well.

Consider a simple coordinate:

value record Point(int x, int y) {}

Two Point objects containing the same coordinates do not need separate identities. What matters is the value represented by their fields. That differs from Java's traditional object model. With ordinary objects, each execution of new creates an object with an identity that distinguishes it from every other object. Two objects can contain identical data and still produce false when compared with == because the operator traditionally compares their references.

Value objects change that behavior.

The draft Java SE 28 language specification(https://download.java.net/java/early_access/jdk28/docs/specs/value-objects-jls.html) describes special semantics for value objects, including how they are instantiated, compared, and used with synchronization.

For value objects, == determines whether the objects are indistinguishable based on their state rather than whether two references identify the same object. That is one reason JEP 401 is more than a new syntax feature. It changes an assumption embedded deep in Java's object model.

Removing identity gives the JVM additional freedom. If an application cannot tell the difference between two value objects containing the same field values, the runtime does not have to preserve a unique identity for each one. JEP 401 says that freedom can allow JVM implementations to improve memory footprint, locality, and garbage collection efficiency.
For example, a JVM may be able to store the fields of a value object more directly rather than always maintaining the representation required for a conventional identity object. But JEP 401 deliberately does not promise a particular memory layout or optimization.

The proposal says its goal is to give the JVM greater freedom to optimize value objects, not to guarantee that every value class will be flattened in memory or produce a particular performance improvement.

That distinction matters for developers evaluating Valhalla as a performance feature. Declaring something a value class expresses a semantic property, namely that the object does not need identity. What the JVM does with that information is an implementation decision.

Project Valhalla describes its broader goal as combining the abstractions of object-oriented programming with the performance characteristics of simple primitives.

Java's Own Classes Will Change…

JEP 401 is not limited to new classes written by application developers. The proposal identifies 30 classes in the java.* APIs that are being declared as value classes when the preview feature is enabled. They include familiar wrapper classes such as Integer, Long, Double, and Boolean, along with classes including Optional, LocalDate, LocalDateTime, and Duration.

Those are not arbitrary choices. Many of these APIs have already been documented as value-based classes because programs generally should not depend on the identity of their instances. Java has also discouraged identity-sensitive operations on some of them. Since Java 16, for example, developers have been warned against synchronizing on value-based classes.

JEP 401 turns that existing programming convention into a property the JVM can understand. It also introduces methods in java.util.Objects that allow code to determine whether an object has identity or require that an object have identity. Reflection support will also expose the distinction.

That means developers experimenting with JDK 28 may encounter value-object behavior without first writing their own value classes.

The behavior of == is likely to be one of the more noticeable parts of the change.
Consider two conventional objects containing the same information. Java developers know that a.equals(b) may return true while a == b returns false, because the latter tests object identity.

With value objects, there is no identity to test. JEP 401 therefore changes object equality so that value objects with indistinguishable state compare as equal with ==. The OpenJDK proposal is careful not to present this as a general replacement for equals(). It explicitly says that the usual recommendation to use equals() for object comparisons in most contexts still applies.

The difference exists because Java has to define what == means when one of the objects being compared has no identity. That can create compatibility concerns. The JEP warns that changing an existing identity class into a value class can cause behavioral incompatibilities if application code has relied on separately constructed objects being distinguishable through ==.

In other words, code that depends on identity where it should have depended on value may finally have that assumption exposed.

Synchronization Is Another Boundary
Identity also matters to Java synchronization. Traditional objects can act as monitors, allowing code to use constructs such as synchronized (object). A value object cannot serve the same role because it lacks the stable identity required by that locking model.

The Java SE 28 draft specification consequently includes special JVM behavior for monitor operations involving value objects.

This is another reason OpenJDK is introducing the feature as a preview. JEP 401 acknowledges that changes to operations such as == and synchronized could surprise developers or expose bugs in programs that depend on identity-sensitive behavior. The proposal's authors say they expect those disruptions to be relatively uncommon and manageable.

It may be tempting to think of value classes as Java's version of a C struct, but that is specifically not the model Project Valhalla is adopting.
JEP 401 lists introducing a struct feature as a non-goal. Java developers are not being given explicit control over where an object is stored or how its fields are laid out in memory. Value objects remain objects, and value classes remain part of the normal Java class hierarchy.

They are subclasses of java.lang.Object, can implement interfaces, and can be used through Object references. Generic APIs such as List and Comparable can also work with value classes. That approach preserves much of Java's existing object-oriented programming model while giving the runtime new information about which objects do not require identity.

Records are particularly natural candidates. Because records are already final and their fields are final, JEP 401 notes that they are often well suited to becoming value classes.

But records and value classes solve different problems. Records primarily provide a concise way to model data aggregates. Value classes tell Java that the instances themselves do not require identity. A class can therefore be both, as in value record Point(int x, int y).

Project Valhalla has been working toward changes to Java's value model for years, and value classes are only part of that greater effort.
As recently as October 2025, OpenJDK engineer Dan Smith described JEP 401 as fully implemented in a special Valhalla early-access build but said considerable work remained before it could enter a regular JDK release. Developers interested in the feature had to download those specialized builds to experiment with it. Smith's Inside.java post provided an early look at the programming model.

That situation has now changed.

Project Valhalla's current documentation says JEP 401 and its companion work on strict field initialization have been integrated and will be included in JDK 28. Developers can experiment with value objects through JDK 28 early-access builds ahead of the release.

The feature will still be a preview, so developers will have to explicitly enable preview features to use it, and its design can change before becoming permanent. But its arrival in the regular JDK release train represents a significant milestone for Valhalla.

For Java developers, the immediate task is not necessarily to start converting classes to value classes. It is to understand the distinction Java is introducing.

For most of Java's history, being an object has meant having identity. Starting with the JDK 28 preview, those two concepts will no longer always be the same thing.