Serialization problem (original) (raw)
Alan Bateman Alan.Bateman at Sun.COM
Sun Jan 31 13:35:58 UTC 2010
- Previous message: Serialization problem
- Next message: Serialization problem
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/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.
- Previous message: Serialization problem
- Next message: Serialization problem
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]