Explicit Serialization API and Security

[Stephen Colebourne]

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

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