Serialization of object identity

[Kłeczek, Michał]

I think it should not be left unspecified as it might lead to nasty 
surprises.

On 14/06/2019 21:05:26, "Brian Goetz" <brian.goetz at oracle.com> wrote:

>
>>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.
>
>