Serialization of object identity
brian.goetz at oracle.com
Fri Jun 14 19:05:26 UTC 2019
> Cycles are one thing but object identity is also needed to maintain
> the shape of object graph in case it is a lattice (not a tree).
> Is the proposal assuming that there are references to shared instances
> and it should be preserved during serialization/deserialization?
That's up to the serialization framework. I could imagine some would
choose to use identity to preserve topology, and others could choose not
to (at the risk of duplication.) And different frameworks can make
different choices. Java serialization already makes a pretty reasonable
attempt to preserve topology, so presumably it would continue to do so.
Another aspect that is left to the serialization framework is _how_ to
find a serializer for a given type. For example, suppose you have a
subtype of List, but which doesn't have any serialization members.
Should we fail because we can't find a serializer/deserializer that will
give perfect fidelity, or could we fall back to a generic
serializer/deserializer pair (perhaps found in List) that would
reconstruct an ArrayList or a List.of(...) list? We don't have to make
one choice for all serialization frameworks.
The emergent property here, that may not be obvious, is that once we
move responsibility for state extraction/reconstruction to the class
itself, core serialization becomes _less relevant_, because there is a
"level playing field" that allows any serialization framework to
participate, without privilege, in the state extraction/reconstruction
part. Then the job of a serialization framework becomes much simpler:
finding serializers for classes, encoding, and decoding.
More information about the amber-dev