Explicit Serialization API and Security

Chris Hegarty chris.hegarty at oracle.com
Tue Jan 6 10:25:49 UTC 2015


On 6 Jan 2015, at 08:31, Stephen Colebourne <scolebourne at joda.org> wrote:

> On 6 January 2015 at 07:27, Peter Levart <peter.levart at gmail.com> wrote:
>> readObject() can be used on both ends of the spectrum or anywhere
>> in-between. It can be used for explicit deserialization or just for
>> validation of default deserialized state. Would separate validation method
>> give us anything more or simplify things? readObject() can be used just as:
>> 
>> private void readObject(ObjectInputStream in) throws IOException,
>> ClassNotFoundException {
>>    in.defaultReadObject();
>>    ...
>>    just validation
>>    ...
>> }
>> Explicit deserialization and final fields don't play nicely together
>> currently, yes. Sometimes data-racey-publication thread-safety is sacrificed
>> just because explicit deserialization would complicate code too much by
>> using reflection.
> 
> 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.

-Chris.

> Using such a method, the input could be read into local variables, and
> then a normal constructor used to create the object itself. It avoids
> the final fields problem (as its just reading to local variables) and
> it handles the validation (by calling a regular constructor/factory).
> Its also more efficient in many cases, as a common pattern today is to
> have one object instance created by readObject (or serialization
> internals) and then another returned by readResolve. If
> readObjectAndResolve() can't handle cyclic graphs, I can live with
> that.
> 
> Stephen




More information about the core-libs-dev mailing list