Serialization problem (original) (raw)

Stephen Colebourne scolebourne at joda.org
Sun Jan 31 20:50:42 UTC 2010

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.Bateman at 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 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/viewbug.do?bugid=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.

More information about the core-libs-dev mailing list