On 6 Jan 2015, at 08:31, Stephen Colebourne <scolebou...@joda.org> wrote:
> On 6 January 2015 at 07:27, Peter Levart <peter.lev...@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
