Explicit Serialization API and Security

[Patrick Reinhart]

> Am 12.01.2015 um 17:15 schrieb Stephen Colebourne <scolebourne at joda.org>:
> 
> 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

That’s the way we mostly implemented the serialization in our product in order to be more open for simpler conversion of enhancements being done on existing classes. In our case we serialize using a proxy class with the writeReplace() on the original and readObject()/readResolve() method on the serialize proxy class. 

One of the most annoying part of the existing Serialization for me that should also be looked into is the way that errors are being reported if something goes wrong while serializing/deserializing objects. In that part I spent the most of my time in the past.

- Patrick