Explicit Serialization API and Security

Stephen Colebourne scolebourne at joda.org
Tue Jan 6 11:55:30 UTC 2015

On 6 January 2015 at 11:46, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> With shallow/no hierarchies, and others, the serialization proxy pattern works quite well. The overhead of course being the creation of the proxy itself, but this is typically a minimal container with just the state needed to create the “real” object, and no behaviour. Whatever the input would have to be to the "static factory” method, readObjectAndWriteReplace, then it would probably have the same overhead, albeit minimal, as the proxy. Though one less serializable type. This could work out nice, but it could not support cyclic graphs ( which I think I could live with ), or private superclass state ( which I think would be limiting ).

I used a shared proxy on 310. Small serialized form (short class name,
shared overhead if more than one type from same package, but no
sharing). Its fine, but quite verbose.

Oh, and to be clear, with readObjectAndResolve() you'd ban
readObject() and readResolve() from being in the same class.

On private superclass state, that state must be settable via the
constructor or setters of the superclass. Providing you control the
superclass and can change your class if the superclass changes, then I
don't see private superclass state as a problem.

private static Object readObjectAndResolve(in) {
  String name = in.readStr(""name")
  int age = in.readInt("age")
  Address addr = in.readObj("address")
 return new Person(name, age, address);

works fine even if name is in the superclass AbstractPerson and
age/address is in Person.


More information about the core-libs-dev mailing list