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.
