Serialisation and Immutability

[Peter <ji...@zeus.net.au>]

This problem has been allowed to fester for a long time.

Serialisation creates all sorts of issues because it doesn't utilise constructors or static factory methods.

I've had enough, I'm doing something about it.

As you may be aware, ObjectInputstream and  ObjectOutputStream are extensible and allow subclasses to substitute any object.

I'm considering creating an interface:

Interface DistributedObject {

    SerialFactory substitute();

}

// Pseudo code; methods and constructors omitted.
public final class SerialFactory implements Externalizable {

    private final Class clazz; // factory class or constructors class
    private final String methodName;  // constructor if null.
    private final Class [] parameterTypes;
    private final Object [] parameters;

}

It's straightforward to create object streams that substitute DistributedObject's in the stream with SerialFactory and replace them using reflection to call a constructor or static method during deserialisation.

This retains compatibility with existing Serialisation and Marshalling, it preserves the object graph and allows distribution and construction of non serializable final immutable objects.  It doesn't suffer from readResolve's circular reference issue either.

It allows object class evolution, migration of data, serial form is separate, flexible and based on static method or constructor parameters, even a completely different implementation can be used simply, by changing factory method implementations (provided all references to an object being deserialised refer to a compatible superclass or interface).

It prevents package classes from being published; eg a private class can utilise a public class static factory method and extend a non serializable class lacking a public no arg constructor (Serializable methods can't do that).

It also allows a transition period to migrate serializable objects to utilise DistributedObject only, if necessary at some later point, removing lock in to currently published serial form for much greater flexibility in future.

It would also allow heavyweight objects to be linked locally from persistant storage or databases (which may be obtained via Services), only requiring serialisation of a small amount of data to obtain a reference, allowing a factory to perform the heavy lifting or construction required to obtain the correct object to be linked into the object graph.

Yes, I'm aware that you can use reflection during deserialization to set final fields to ensure immutability and invarients, unfortunately programmers seldom use this trick, I want something simpler that gets rid of boilerplate code, where most of the hard work is done for you, all the developer needs to do is implement one method to construct a SerialFactory which utilises constructors and factory methods

Sorry, I'm just getting fed up with legacy code making life hard.

Peter.