Explicit Serialization API and Security

[Chris Hegarty]

On 6 Jan 2015, at 11:13, Stephen Colebourne <scolebourne at joda.org> wrote:
On 6 January 2015 at 10:25, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> On 6 Jan 2015, at 08:31, Stephen Colebourne <scolebourne at joda.org> wrote:
>>> I've thought on a number of occasions that what I wanted from
>>> serializable was a merger of readObject and readResolve
>>> 
>>> private Object readObjectAndResolve(ObjectInputStream in) throws IOException
>> 
>> This is an interesting idea.
>> 
>> Just so I understand, readObject is called down the inheritance hierarchy and can read, into locals, its classes serializable fields ( of course if can access its super types fields that are already set ), where as just a single readResolve call is made, if it is defined by or accessible (via inheritance) by the given class.
> 
> I tend to work with shallow/no hierarchies so I've not thought too
> much about the detail. I'd imagine you'd want to have
> readObjectAndResolve() be a static method called only on the class
> being deserialized and not superclasses. The method itself would be
> responsible for any superclass deserialization. (Static because there
> is no instance to call it on and it should have no access to instance
> variables). It may be that the input should not be ObjectInputStream,
> but some simpler but related type.

With shallow/no hierarchies, and others, the serialization proxy pattern works quite well. The overhead of course being the creation of the proxy itself, but this is typically a minimal container with just the state needed to create the “real” object, and no behaviour. Whatever the input would have to be to the "static factory” method, readObjectAndWriteReplace, then it would probably have the same overhead, albeit minimal, as the proxy. Though one less serializable type. This could work out nice, but it could not support cyclic graphs ( which I think I could live with ), or private superclass state ( which I think would be limiting ).

-Chris.

> Stephen