[gclist] object hash codes and copying collection

[Mark Tillotson]

"Bryan O'Sullivan" <bos@serpentine.com> wrote:
| 
| Right.  The other general expectation of an object's hash code in Java
| is that if two objects are "the same" according to Object.equals, they
| should have the same hash code.
| 

I think the original poster was only talking about the native hashCode()
method provided by java.lang.Object.  The requirement about equals()
is thus irrelevant (the similar requirement about == is subsumed by
the requirement that hashCode() always returns the same value for a
given object.)


| e>   - Object hash codes are distributed such that one can find hash
| e>     functions over the hash codes that distribute the objects into
| e>     hash bins uniformly (with high probability).
| 
| This is, unfortunately, a very soft requirement indeed.  Scrutiny of
| many of the classes in the standard JDK1.1 java.* classes reveals what
| might generously be called questionable choices of hash code
| generators in several instances

hashCode() merely follows equals(), so you are questioning the notion
of equality in these classes.  Of course there are usually several competing
equivalence classes for a particular class, so which one gets chosen
for equals() is going to necessarily be arbitrary...

Anyhow, hasn't this discussion rather strayed away from the memory
management issues by now?

__Mark
[ markt@harlequin.co.uk | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]