Hello, please consider this statement: HashCode() SHOULD be overrridden in classes which have their own equals method but hashCode() MUST Be overridden in classes classes that are to be stored in a HashSet. These classes must implement the hashCode() and equals() method. Questions: 1. Is the statement above correct? 2. Why must HashSet implement the equals method, too? How does HashSet use the equals method? Appreciate your answers. Thomas
If you override equals(), you MUST override hashCode() if there is any possibility whatsoever that your object will be used as the key in a Hashtable, HashSet, HashMap, LinkedHashSet, or LinkedHashMap. It's best not to think too hard about this, and simply ALWAYS override hashCode() whenever you override equals(). When you look up a value in a HashSet with contains(), the HashSet will first find elements with the same hashCode() as the argument, then compare each one using that element's equals() method.
Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Joined: Mar 08, 2001
Hello Ron, I checked out what you said and found out that your statement is not only valid for the proper function of the contains() method but for the add() method, too. It seems if you create your own class like "Employee" and want to store it properly in a HashSet then you have to override hashCode and equals: In the following programs I want to check out the effects of „equals()“ and hashCode() on a HashSet. The result is that if you create a Set with objects of a class of your own (like „Employee“ you have to override equals() and hashCode() in your class. Otherwise your HashSet will not work properly for instance if you add() a new element into a HashSet then it shouldn’t accept any duplicates. To find out whether a new element is already in the set it relies on the hashCode() and the equals() method to find that out. It first looks for elements with the same hashCode() as the element which should be added. Therefore it has to call you overridden hashCode() method in class „Employee“. If it finds an object in the set with the same hashCode as the added element then it calls the overridden equals() method to check for „real equality“ as the same hashCode is not a 100% ouarantee for object equality. If the hashCode() and equals() method is not implemented in the class „Employee“ (like in Employee_Test3) then you can add duplicate employees. Only if you override equals() properly like in „Employee_Test3a“ then you can ensure that your HashSet will not contain duplicate „Employee“ entries.
The relationship between hashCode() and equals() is part of the contract for Object. Any method anywhere is entitled to assume that hashCode() is consistant with equals(). Overriding equals() without supplying a legal hashCode() is asking for trouble. If you want to override equals but don't want to spend much time designing a suitable hashCode, consider that you can comply with the contract for Object with something as simple as
That's won't make for efficient hashing, but it will keep code that uses hashCode() correctly from giving the wrong answer. Or, if you want to treat use of hashCode() as a programming error, consider using However, I don't think I've ever had to do either of these. I've found that when it makes sense to override equals, it is easy enough to provide a reasonable hashCode(). [ November 17, 2002: Message edited by: John Dale ]
You may want to take a look at Roedy Green's Java Glossary on hashCode for a decent explanation and an idea of how to implement a hashCode algorithm. If anybody's looking for more examples of hashCode algorithms, the source code that ships with J2SE is probably full of examples.