Re: hashCode and equals (again)
Hendrik Maryns wrote:
Yes. There generally is no need to make your equals() function that
complex, that it depends on hashCode()
It's generally an outright bad idea to base equals() on hashCode(), not merely
unnecessary.
Todd wrote:
2. When would one use a set of criteria to determine equality that is
different from the criteria used to generate a hashCode?
If you had bothered to read the Javadocs for hashCode(), you'd have seen:
The general contract of hashCode is:
* Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently
return the same integer, provided no information used in equals
comparisons on the object is modified. This integer need not remain
consistent from one execution of an application to another execution
of the same application.
* If two objects are equal according to the equals(Object) method,
then calling the hashCode method on each of the two objects must
produce the same integer result.
* It is not required that if two objects are unequal according to
the equals(java.lang.Object) method, then calling the hashCode method
on each of the two objects must produce distinct integer results.
However, the programmer should be aware that producing distinct integer
results for unequal objects may improve the performance of hashtables.
Todd:
3. Why aren't the hashCode_s in the following code the same?
Hendrik Maryns:
Arrays are objects. hashCode() for an array is the hashCode of Object,
which is simply based on its place in memory,
Sort of, but not really. Since objects move around in memory in the JVM,
there's no way that a non-volatile hash code could always represent a "place
in memory" in any meaningful way.
Question I forgot:
Should the hashCode be used as an equality criteria ~ as long as it is
combined with some other criteria?
No, it should not.
Isn2"t that covered by your first question? I2"d say 2?no2".
Would be perfectly valid, although I would suggest to change hashCode to
something like
@Override public int hashCode() {
return i ^ j;
}
Experts will be able to tell you more about how to combine i and j,
there are some reasons for not using 2?+2".
No there aren't. A typical approach for a 32-bit integer hash is to use:
int hash = i * 31 + j;
with an appropriate narrowing cast if i or j are wider than int. (You can
extend this to /n/ elements by induction.)
Donald Knuth <http://en.wikipedia.org/wiki/Donald_Knuth>,
goes into hashes rather thoroughly in /The Art of Computer Programming/. On
line there's <http://en.wikipedia.org/wiki/Hash_code> and a host of other
googlable references.
--
Lew