Serialization problem

Goktug Gokdogan gokdogan at
Sun Jan 31 04:04:45 UTC 2010

I would put the first element to a different field, make periods field
transient and implement a readResolve method that calls a constructor.

So, something like this should solve your problem easily, right?

 private final String name
 private final Duration duration
 private final PeriodField firstPeriod
 private final transient List<PeriodField> periods
 private final transient int hashCode

 private Object readResolve() throws {
    return new MyImmutableClass(name, duration, firstPeriod); //you can
define a private constructor if required

On Sat, Jan 30, 2010 at 7:44 PM, Stephen Colebourne <scolebourne at>wrote:

> 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<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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the core-libs-dev mailing list