ObjectInputStream SPI

[Peter Firmstone]

Thanks Chris,

Over the last year I've been working on reimplimenting OIS, I've been able to retain serial form compatibility, but have made some changes to deserialization api.

With the reimpl, existing Serializable objects that are stateless or those with only primitive fields are allowed to be deserialized.

DeserializationPermission is required for classes with Object fields or that read input from the stream.  A context is constructed from every class in the object's inheritance hierarchy and checked by the sm.

I've chosen not to support private readObject methods and utilise annotations and constructor signatures instead, to allow failure atomicity.

I've created a utility class with static methods that perform common invariant validation, such as null check, collection element type checks and defensive copying.  These methods can be chained and throw InvalidObjectException.  For most cases these utility methods allow the developer to simplify or eliminate the need to implement their own static validation methods.

I've added two new public methods to OIS:

<T> T readObject(Class<T> type)

and another similar method for readUnshared.

In this case the object is type checked for assignment compatibility before deserialization.  This presents compatibility issues with the Serialization proxy pattern however.  Solution: if a readResolve method is defined, its return argument type is checked, before deserialization occurs.  Presently according to the serialization spec, the only allowed return type is object, any chance of allowing covariant return types for readResolve?

Java collection classes are replaced in the stream with serializers for Map SortedMap, SortedSet, Set and List, this avoids array length issues or deliberate hash collisions.  Client code must check all types within the collections when creating a defensive copy.

At this time circular object graphs are not supported.

I realise these changes aren't possible for standard java serialization as too many breakages would occur.

As this OIS will be exposed to untrustred data, I must ensure it is not be subject to gadget or dos style attacks.

Regards,

Peter.

Sent fro  m my Samsung device.