Serialization problem

[Stephen Colebourne]

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<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.
>
>
>