Re: [Classpath] Bug in Double.java

[Jochen Hoenicke]

On Jul 16, C. Scott Ananian wrote:
> On Mon, 16 Jul 2001, Eric Blake wrote:
> 
> > Someone will need to check my work with serialization issues, as I am not
> > very familiar with the process.  Basically, my added hashCode() caching will
> > break if a deserialization restores the transient hashCode field to 0
> > instead of -1.  I chose -1 for the non-cached value instead of 0, since new
> > Double(0).hashCode() == 0, but left the cache field transient so it will
> > interoperate with serial streams from other sources.  Maybe it's not worth
> > caching the result of hashCode() after all.
> 
> Fields marked transient are *defined* to be reset to zero after
> deserialization.  Use 0 as your non-cached value; the only "harm" will be
> that hashCode will have the same performance as the non-caching version
> for Double(0) -- it's still better than not caching at all.

Another possibility is to add a readObject method, that just calls
defaultReadObject() and initializes the transient fields to correct
values.  See Classpath's implementation of java.util.Locale as an
example.

  Jochen