Serialization problem (original) (raw)
Goktug Gokdogan gokdogan at gmail.com
Sun Jan 31 04:04:45 UTC 2010
- Previous message: Serialization problem
- Next message: Serialization problem
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I would put the first element to a different field, make periods field transient and implement a readResolve method that calls a constructor.
So, something like this should solve your problem easily, right?
private final String name private final Duration duration private final PeriodField firstPeriod private final transient List periods private final transient int hashCode
private Object readResolve() throws java.io.ObjectStreamException { return new MyImmutableClass(name, duration, firstPeriod); //you can define a private constructor if required }
On Sat, Jan 30, 2010 at 7:44 PM, Stephen Colebourne <scolebourne at joda.org>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() But, when you implement readObject(), you cannot store the read values into the fields because they are final. Nor can I stash them somewhere ready for readResolve(). From my perspective, what I need is a combined readObject() and readResolve(): private Object readObjectAndResolve() I could then read the stream, and call the constructor to properly initialise the object state (including the full period list and hash code caches). This seems to be a general problem with deserializing immutable classes. Workarounds include lazily creating the caches in transient fields, bloating the serialzed data, using reflection or creating a dummy inner class to act as the serialized form. All are rubbish solutions. Any suggestions? And if not, what about adding the suggested method to the JDK? Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100130/a01c1aeb/attachment.html>
- Previous message: Serialization problem
- Next message: Serialization problem
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]