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