# {@index "Value-based Classes"}

Some classes, such as {@code java.lang.Integer} and {@code java.time.LocalDate}, are value-based. In a future release, they may become value classes (JLS {@jls value-objects-8.1.1.5}).

A value-based class has the following properties:

- all instance fields declared in the class and all of its superclasses are final (though these may contain references to mutable objects);
- the class's implementations of {@code equals}, {@code hashCode}, and {@code toString} compute their results solely from the values of the class's instance fields (and the members of the objects they reference), not from the instance's identity;
- the class's methods treat instances as freely substitutable when equal, meaning that interchanging any two instances {@code x} and {@code y} that are equal according to {@code equals()} produces no visible change in the behavior of the class's methods;
- the class performs no synchronization using an instance's monitor;
- the class does not declare, or discourages use of, accessible constructors (because each constructor call promises a unique identity);
- the class does not provide any instance creation mechanism that promises a unique identity on each method call—in particular, any factory method's contract must allow for the possibility that if two independently-produced instances are equal according to {@code equals()}, they may also be equal according to {@code ==};
- the class is final, and extends either {@code Object} or a hierarchy of abstract classes.

When two instances of a value-based class are equal (according to `equals`), a program should not attempt to distinguish between their identities, whether directly via reference equality {@code ==} or indirectly via an appeal to synchronization, identity hashing, serialization, or any other identity-sensitive mechanism.

Synchronization on instances of value-based classes is strongly discouraged, because the programmer cannot guarantee exclusive ownership of the associated monitor.

When preview features are enabled, some value-based classes become value classes. Instances of these classes become value objects, which have different identity-related behaviors compared to identity objects:

- Previously distinguishable instances, such as those created from distinct constructor invocations (See JLS {@jls value-objects-15.9.4}), may be no longer distinguishable via {@code ==}.
- The use of value objects for synchronization or with {@linkplain java.lang.ref.Reference object references} results in {@link IdentityException}.