Serialization problem (original) (raw)

Stephen Colebourne scolebourne at joda.org
Sun Jan 31 00:44:14 UTC 2010

I thought I'd raise an issue with serialization that I've had a problem with more than once. Perhaps there is an obvious easy solution, but I can't see it (I can see hard workarounds...)

In JSR-310 we have lots of immutable classes. One of these stores four fields:

private final String name private final Duration duration private final List periods private final int hashCode

For serialization, I only need to store the name, duration and element zero from the periods list. (The rest of the period list is a cache derived from the first element. Similarly, I want to cache the hash code in the constructor as this could be performance critical.). Storing just these fields can be done easily using writeObject()

But, when you implement readObject(), you cannot store the read values into the fields because they are final. Nor can I stash them somewhere ready for readResolve().

From my perspective, what I need is a combined readObject() and readResolve():

private Object readObjectAndResolve()

I could then read the stream, and call the constructor to properly initialise the object state (including the full period list and hash code caches). This seems to be a general problem with deserializing immutable classes.

Workarounds include lazily creating the caches in transient fields, bloating the serialzed data, using reflection or creating a dummy inner class to act as the serialized form. All are rubbish solutions.

Any suggestions? And if not, what about adding the suggested method to the JDK?

Stephen

More information about the core-libs-dev mailing list