Serialization problem

Stephen Colebourne scolebourne at
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 

  private final String name
  private final Duration duration
  private final List<PeriodField> 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 

  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?


More information about the core-libs-dev mailing list