Why should Java's value-based classes not be serialized?

Question

Since Version 8 Java has the concept of value-based classes. This is in preparation of a future version which will most likely allow the definition of value types. Both definitions/descriptions mention serialization (bold face added by me):

About the existing value-based classes:

A program may produce unpredictable results if it attempts to distinguish two references to equal values of a value-based class, whether directly via reference equality or indirectly via an appeal to synchronization, identity hashing, serialization, or any other identity-sensitive mechanism.

About future value types:

The default identity-based hash code for object, available via System.identityHashCode, also does not apply to value types. Internal operations like serialization which make identity-based distinctions of objects would either not apply to values (as they do not apply to primitives) or else they would use the value-based distinction supplied by the value type’s hashCode method.

Because future JVM implementations might not use object headers and reference pointers for value-based classes, some of the limitations are clear. (E.g. not locking on an identity which the JVM must not uphold. A reference on which is locked could be removed and replaced by another later, which makes releasing the lock pointless and will cause deadlocks).

But I don't get how serialization plays into this. Why is it considered an "identity-sensitive mechanism"? Why does it "make identity-based distinctions of objects"?

Answer 1

Serialization uses System.identityHashCode (via IdentityHashMap) to ensure that the topology of the object graph resulting from deserialization is topologically equivalent to that of the input graph.

Answer 2

Think what happens when the object graph being serialized has a cycle. The serialization algorithm would enter an endless loop in such a case—unless it has a specific mechanism to detect and resolve cycles. We all know that Java's serialization allows cyclic object graphs, therefore the mechanism is there.

Now consider the definition of a cycle: the graph contains an object which is reachable from itself. That definition refers to object's identity, which means that the mechanism must consider object identity to track cycles. On the implementation level this is achieved by maintaining an IdentityHashMap of all seen instances, and that class relies on Object.identityHashCode().

The sentence you quote explains how this issue will be resolved in a future version of Java: value types will be given special treatment such that the cycle detection will rely on their own equals and hashCode methods instead of == and identityHashCode.