5

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?

Holger
  • 285,553
  • 42
  • 434
  • 765
sagar
  • 53
  • 5

1 Answers1

6

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.

Holger
  • 285,553
  • 42
  • 434
  • 765
  • 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? – Eugene Dec 21 '17 at 13:12
  • 3
    @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)… – Holger Dec 21 '17 at 13:30
  • 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 – Eugene Dec 22 '17 at 13:02
  • @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… – Holger Dec 22 '17 at 13:15
  • @Eugene: But don’t forget, `Optional` is not serializable, so let’s consider single element `List.of(…)` instead… – Holger Dec 22 '17 at 13:17