On 6 January 2015 at 11:46, Chris Hegarty <chris.hega...@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.
Stephen
