Thanks for the info. Unfortunately, JSR-310 cannot use unsafe, as it needs to be usable outside the JDK.
For info, I compared the sizes of a neatly trimmed output (using a Serialization proxy class) with the best achievable without one. 277 bytes without, 99 bytes with a proxy. So, this isn't an esoteric problem. What would you think of using a ThreadLocal to cache the result value between readObject() and readResolve() ? (making everything transient and using a dedicated format) What do you think of the general idea of readObjectAndResolve() ? (for JDK 7+) Stephen On 31 January 2010 13:35, Alan Bateman <alan.bate...@sun.com> wrote: > 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. > > >
