Value Objects Would Be Distinguished Only by Their Field Values, Not by Identity, Providing an Easier Programming Model for Simple Values
An OpenJDK proposal aims to introduce value classes and objects in a future version of Java, offering a new approach to representing simple values in the language. The feature, which provides class instances with only final fields and no inherent object identity, was first proposed in August 2020 and updated on June 21.
The core idea behind this proposal is to enable a programming model where objects are identified solely by their field values, similar to how primitive values are compared. For example, the value 3
is inherently different from 4
, and this distinction would be mirrored in the new value classes. This model simplifies handling simple values, making it easier to manage and compare them in code.
Another key objective of the proposal is to facilitate the migration of commonly used classes that represent simple values in the Java Development Kit (JDK), such as Integer
, to this new model. This migration is designed to be compatible with existing code, allowing user-defined classes to adopt the value class model seamlessly.
The proposal also aims to enhance the efficiency of the Java Virtual Machine (JVM) by allowing it to encode simple values in ways that improve memory usage, locality, and garbage collection performance. By leveraging the new value class model, the JVM could optimize storage and processing of these values.
It’s important to note that the proposal is currently slotted as a preview feature and does not specify a targeted version of Java for its release. The introduction of value classes is not intended to include a struct feature or alter the treatment of primitive types. Existing classes will not be automatically converted to value classes, preserving the distinction between objects and primitives in Java.
Overall, this proposal represents a significant shift in how Java handles simple values, potentially simplifying the programming model and improving performance, while maintaining Java’s existing paradigms.