Serialization problem

[Alan Bateman]

Stephen Colebourne 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()
In the JDK there are places that use unsafe's putObjectVolatile to 
workaround this. It's also possible to use reflection hacks in some 
cases. There is more discussion here:
  http://bugs.sun.com/view_bug.do?bug_id=6379948

Doug Lea and the concurrency group were working on a Fences API that 
included a method for safe publication so that one can get the same 
effects as final for cases where it's not possible to declare a field as 
field.

For the hashCode case above then perhaps it doesn't necessary to compute 
the hash code in the constructor or when reconstituting the object. 
Instead perhaps the hashCode method could compute and set the hashCode 
field when it sees the value is 0 (no need to be volatile and shouldn't 
matter if more than one thread computes it).

-Alan.