0

I know there are lots of similar questions out there but I have not satisfied by the answers I have read. I tried to figure it out but I still did not get the idea. What I know is these two are important while using set or map especially HashSet, HashMap or Hash objects in general which use hash mechanism for storing element objects.

Both methods are used to test if two Objects are equal or not. For two objects A and B to be equal first they need to have the same hash value( have to be in the same bucket) and second we have to get true while executing A.equals(B).

What I do not understand is, WHY is it necessary to override both of these methods. WHAT if we do not override hashcode. IS IT A MUST TO OVERRIDE BOTH.If it is not what is the disadvantage of overriding equals and not hashcode and vice versa.

Tesfa Zelalem
  • 619
  • 1
  • 9
  • 18
  • 2
    Have you looked [What issues should be considered when overriding equals and hashCode in Java?](http://stackoverflow.com/questions/27581/what-issues-should-be-considered-when-overriding-equals-and-hashcode-in-java/27609#27609). Generally speaking, there is a contractual requirement that any object's that are `equal` also produce the same `hashcode` – MadProgrammer Oct 07 '15 at 03:07

2 Answers2

1

Properly implementing hashCode is necessary for your object to be a key in hash-based containers. It is not necessary for anything else.

Here's why it is important for hash-based containers such as HashMap, HashSet, ConcurrentHashMap etc.

At a high level, a HashMap is an array, indexed by the hashCode of the key, whose entries are "chains" - lists of (key, value) pairs where all keys in a particular chain have the same hash code. For a refresher on hashtables, see Wikipedia.

Consider what happens if two keys A, B are equal, but have a different hash code - for example, a.hashCode() == 42 and b.hashCode() == 37. Suppose you write:

hashTable.put(a, "foo");
hashTable.get(b);

Since the keys are equal, you would like the result to be "foo", right? However, get(b) will look into the chain corresponding to hash 37, while the pair (a, "foo") is located in the chain corresponding to hash 42, so the lookup will fail and you'll get null.

This is why it is important that equal objects have equal hash codes if you intend to use the object as a key in a hash-based container.

Note that if you use a non-hash based container, such as TreeMap, then you don't have to implement hashCode because the container doesn't use it. Instead, in case of TreeMap, you should implement compareTo - other types of containers may have their own requirements.

jkff
  • 17,623
  • 5
  • 53
  • 85
0

Yes it's correct when you override equals method you have to override hashcode method as well. The reason behind is that in hash base elements two objects are equal if their equals method return true and their hashcode method return same integer value. In hash base elements (hash map) when you make the equal check for two objects first their hashcode method is get called, if it return same value for both then only equals method is get called. If hashcode don't return same value for both then it simplity consider both objects as not equal. By default the hashcode method return some random value, so if you are making two objects equal for some specific condition by overriding equals method, they still won't equal because their hashcode value is different, so in order to make their hascode value equal you have to override it. Otherwise you won't be able to make this object as a key to your hash map.

Gaurav Jeswani
  • 4,410
  • 6
  • 26
  • 47
  • I'm not sure what you're referring to as "the equal check"? hashCode only matters in hash-based containers: e.g., HashMap.put(key, value) will compute the hash of the key and then compare it for .equals() with other keys that have the same hash, so it is important that these methods be consistent. But an object that doesn't implement hashCode will work perfectly well in, say, a TreeMap (in that case it has to properly implement compareTo though). – jkff Oct 07 '15 at 03:23
  • @proudandhonour Is it like if I override equal and not the hashcode it means that I am risking to define two objects that are supposed to be equal as not equal ? – Tesfa Zelalem Oct 07 '15 at 03:28
  • Yes, when you make hash based equals. Example: If you make your object as key to HashMap and you have override equal method and not the hashcode method, you will never find your object in map until unless the object you are searching for and the key in map are both same object(having same memory location in JVM). – Gaurav Jeswani Oct 07 '15 at 04:08