Serialization of object identity

[Kłeczek, Michał]

On 14/06/2019 20:42:07, "Brian Goetz" <brian.goetz at oracle.com> wrote:

>One can surely construct a protocol that "rescues" cyclicity in plenty of ways (e.g., segregate final state from mutable, set the former in a constructor, the latter in a post-construct mutation, and have the serialization framework topologically sort on identity.)   "Is it possible" is not the question; the question is, whether the incremental benefit is worth the incremental cost, in all its varying dimensions (including additional cognitive load on the application developer, and increased attack surface.)
>
>I wouldn't characterize where we are as "giving up", as much as choosing an initial target that embodies a set of cost, complexity, and security tradeoffs.  If it turns out that set of tradeoffs is not workable, or a better set makes itself evident, we can adjust as we go forward.  But I don't think we want to load ourselves up with every possible requirement out of the gate; it has taken long enough for a credible alternate story to emerge already!  And don't forget -- much of the disaster of existing serialization comes from the complexity that came with the various knobs nailed on the side.  So we should be very careful about what requirements we assume.  I'd rather look at it as "is it practical to live without cycle support", rather than "is cycle support possible."
>
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?

--
Michal