the hashCode() contract

[j2me64]

according to my scjp book (Exam 310-065) there are no hashCode requirements when x.equals(y) otherwise I would have a problem for a class Person that has a field name as String. Instantiating two Persons with new Person("May") and new Person("Amy") equals() returns true, but for me equals() should return false, since May and Amy are not the same. I override equals() so that each char is compared with the other char and if one comparison fails equals() returns false. So far all ok. but suppose you sould generate also a different hashCode for the two Strings May and Amy, how?

All other conditions and requirements for a valid hashCode() contract are clear!

[DarrylBurke]

There's absolutely no requirement that different instances of the same class, for which equals(...) returns flase, must have differing hashCode. In fact, it's usually impossible, as the number of different, non-equal instances is usually more than Integer.MAX_VALUE.

A well distributed hashCode can however improve the performance of a hash based collection (Hashtable, HashMap etc). If you're never going to use instances of the class in a hash based collection, you might as well have hashCode() return 0 (or 1, or any constant).

For more, search the net for "hashcode collision"

db