This requirement applies only to classes that you will put into <set> collections (maybe other collections, too; I've only used <set> so far). The reason is that sets use equals() to enforce non-duplicates, and HashSet uses hashCode() as a first-cut
test for equality. I guess technically hashCode() isn't necessary then since equals() will always be used in the end, but providing a meaningful hashCode() will improve performance for very large sets or objects that take a long time to compare using equals().
Let's start with equals(). You need to define what equality means for each of your objects. Take a simple Employee example.
Now, when are two Employees equal? If their first and last names match, they're
probably the same employee, but that's not guaranteed. The same is true of Social Security Number, but they are designed to be not repeat for a long time (if I remember correctly; clearly there are more than 999,999,999 people so SSN can't always be unique), and most companies use this as their unique identifier. Just as important, an Employee's SSN will not change while the application is running.
All this together makes SSN a pretty good choice for equality().
For hashCode(), I recommend reading the
JavaDocs. It describes what rules the method must follow, especially with regard to the equals() method. The short of it is, you typically use the same information to calculate the hash code value as you used to determine equality.
One important thing is that you do not change the Employee fields that are used for equality and hashing after puttnig them into a Set. The reason is that the Set will not be told that the hash code value has changed. If you do need to change an Employee's SSN, you must remove them from all Sets that contain them, change the value, then re-add them to the Sets.
Here's a simple program to demonstrate what happens if you don't follow the above rule.
Note this is for JDK 1.5. Just remove the <TestHashSet> suffixes from the HashSet declaration and instantiation. And here's the output.
Notice that the Set allowed a duplicate TestHashSet (Bob) to be added since the first Bob is still stoerd under the hash code 127.
Let me know if you have any questions with this. While the latter part may seem complicated, under typical usage (read object containing Set, remove some children, add some children, save object) you won't have to worry about it. Even if you load the object, change some fields used for the hash code value, and save the object
you should be okay since you aren't adding new children at the same time (though you use a second-level cache you may run into problems).
[ January 29, 2005: Message edited by: David Harkness ]