Explicit Serialization API and Security

[Stephen Colebourne]

On 12 January 2015 at 11:37, Chris Hegarty <chris.hegarty at 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