[gclist] object hash codes and copying collection
Wed, 10 Dec 1997 17:14:38 GMT
"Bryan O'Sullivan" <firstname.lastname@example.org> 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
| 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?
[ email@example.com | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]