Serialization patch and question

[Christopher Smith]

>On Feb  3, 1999, Godmar Back <gback at cs.utah.edu> wrote:
>>> Before I start working on this, is there any chance of using default
>>> Object.equals() and Object.hashCode() methods on an object of a derived
>>> class, which redefines them as something else, besides "going native"?
>> I am not sure I understand everything you say, but there is
>> System.identityHashCode(Object o), which return the hashcode that would
>> be returned if Object.hashCode() is not overridden.
>> In Kaffe, it returns the address of the object --- which opens a whole
>> new can of worms once we'll use moving collectors.
>Once we start using moving collectors, we'll have to hack
>Object.hashCode() (and identityHashCode) so that they keep returning
>the same value even after the object moves.  The hashcode of an object
>cannot change during its lifetime (and I'm not sure it should change
>after WriteObject | ReadObject)
Actually, this corrected in an addendum to JDK 1.1.x and in JDK 1.2. In
actual fact hashCode() can return a different value, so long as one of the
elements used when performing the equals() comparison has changed. This was
to prevent the obvious dilemma of two object who were never allowed to
become equal, no matter how similar they became.

This doesn't affect indentifyHashCode().

--Chris