On 12 January 2015 at 11:37, Chris Hegarty <chris.hega...@oracle.com> wrote: > For clarity, I would like to describe how things currently work. > > 1) Allocate a new instance of the deserialized type. > 2) Call the first non-Serializable types no-arg constructor > ( may be j.l.Object ). > 3) For each type in the deserialized types hierarchy, starting > with the top most ( closest to j.l.Object ), > 3a) create objects representing all fields values for the type > [this step is recursive and will go to 1 until all > non-primitive types have been created ] > 3b) [ holder for invariant validation ] > 3c) assign objects to their respective members of the > containing instance
Just to note that for me, the problem is that (1) happens at all. IMO, serialization should be separated entirely. Objects should only be created via standard constructors or factory methods. That is the direction that the static readObjectAndResolve() was in. Talk of dedicated serialization constructors or more use of unsafe doesn't really strike me as much of a way forward, except perhaps where compatibility is concerned. Stephen
