This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Building Blockchain Apps and have Michael Yuan on-line!
See this thread for details.
Win a copy of Building Blockchain Apps this week in the Cloud/Virtualization forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
Sheriffs:
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
Bartenders:
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

equals() and hashCode()

 
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Why do I hear this sentence quite often "When you override equals() method, override hashCode() method also". From the following code, without hashCode() method, I am able to compare and print true. Also, I am thinking that hashCode() is useful only if we use either HashSet or HashMap. Am I correct/ wrong? Please advice
 
Sheriff
Posts: 14691
16
Eclipse IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This answer is in the API of the Object#equals method :

API wrote:
Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.


 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is good to follow the contract because there may be other guys in the team who wants to put the Objects in the Hash Collections<HashMap, HashSet>.

This can result in giving some unusual behavior and unexpected results.
 
Ranch Hand
Posts: 83
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh ok.
So does this mean, (as Harikrishna pointed out), that we need to use HashCode implementation just for HashSet, HashTable and HashMap?
Wont we need to implement it for TreeMap too?
 
Harikrishna Gorrepati
Ranch Hand
Posts: 423
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rikesh Desai wrote:Oh ok.
So does this mean, (as Harikrishna pointed out), that we need to use HashCode implementation just for HashSet, HashTable and HashMap?
Wont we need to implement it for TreeMap too?



Hi Rikesh, Christophe and Himanshu are saying something like this. Add this code to the program.


Do you see, we are getting 2 different outputs (may differ in your system), which it should NOT be as per contract. We need to implement hashCode() wherever you write equals() method. That's why String and wrapper classes implements these 2 methods.
 
Ranch Hand
Posts: 155
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Harikrishna Gorrepati wrote:
I am thinking that hashCode() is useful only if we use either HashSet or HashMap.



Rikesh Desai wrote:
So does this mean, (as Harikrishna pointed out), that we need to use HashCode implementation just for HashSet, HashTable and HashMap?



hashCode() is method in java.lang.Object
As all classes inherit java.lang.Object, hanshCode() is also inherited.
It can be used in any class, only thing is that equals() should maintain general contract with hashCode() as told by Christophe Verré
 
He does not suffer fools gladly. But this tiny ad does:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!