Is it ok to Serialize Value based objects if the application never relies on its object identity?

Question

Sonar shows

Make this value-based field transient so it is not included in the serialization of this class.

This is a future-proof bug when value-based class will be released.

So, if the application never relies on its object identity can I make value-based objects non-transient?

Genu

Answer 1

To make a field of a value-based class non-transient, the value based class must be serializable. So it’s actually a design decision not made by you.

If the designer declares a class to be value-based and implementing Serializable, they assume that value based classes and Serialization are compatible and will stay so.

We don’t know, how the final value type implementation will look like, but the migration path offered by the JRE developers, e.g. when introducing the immutable lists, being value based and serializable, should be taken, rather than assuming that there are additional rules and constraints beyond the specification.

After all, there is no reason to assume that Serialization won’t work with value types. It supports primitive values as well and has been adapted in the past too, e.g. when enum support was added. It’s not clear whether it will always store the values then or still support back references like with ordinary objects or perform an entirely different canonicalization, but as long as you don’t rely on the object identity, as was your premise, you’re on the safe side, as either strategy would work with your code.

Madura

my small brain does not digest this, so basically we say these are value types + they implement Serializable => never rely on their identity (via ==?), use equals instead? – Chesty

@Eugene: always using equals instead of == applies to value types in general. Now, Serialization stores and restores identities using back-references to already encountered objects, but since value types have an unspecified identity, you must not rely on this. Future versions might behave as if using writeUnshared, but the opposite is also possible, equal values might become identical instances (if you assume them to be still objects)… – Madura

thank you for keeping me up until 3AM reading this serialization issues (if only SO could pay my bills directly... ). So if I serialize two instances (that are equals, but are not ==) of Optional today I would be writing two different instances; in a value type world I would be writing just one. But since they are immutable why would this matter? It's not like you can get a "lost update" via writeObject of two subsequent writes? I hope I make some sense here – Chesty

@Eugene: not exactly. In a value type world, you are not writing instances, but values, so the terms “different instances” or “the same instance” become meaningless. Think about it this way: an optional is an encapsulated reference (unless empty). So writing an optional means “write that reference and some meta information to restore it to an Optional”. Reading this information would be equivalent to reading the reference and calling Optional.of(…), which may or may not create the same instance for the same reference, though, “in a value type world”, “same instance” is again meaningless… – Madura

@Eugene: But don’t forget, Optional is not serializable, so let’s consider single element List.of(…) instead… – Madura