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"?

The actual question and the question in the topic are completely distinct. — Chris311, Mar 01 '18 at 08:14

score 15 · Accepted Answer · answered Oct 19 '14 at 15:12

15

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.

answered Oct 19 '14 at 15:12

Brian Goetz

90,105
23
150
161

1

This is my point -- identity is primarily relevant to graph algorithms to preserve topology; ie, avoid looping on cycles. – Thomas W Feb 17 '15 at 03:48
6

This answer only points out why identity may play a role in the deserialization process. However, I cannot see why that means that “value-based classes [should] not be serialized,” which seems to be the original question. (Even if the OP seems to be satisfied with the answer.) – Michael Piefel Aug 29 '16 at 15:30
13

What would be the alternative to this ? How would I serialize an object that has a localdate field – jtkSource Mar 19 '17 at 09:26
7

Also, if this was the case why make LocalDate Serializable? – jtkSource Mar 19 '17 at 09:38
2

Why does LocalDateTime implements Serializable? – Andremoniy Dec 18 '17 at 09:51

Marko Topolnik · Answer 2 · 2014-10-19T15:37:30.163

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.

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

2 Answers2

Linked