• Post Reply Bookmark Topic Watch Topic
  • New Topic

why to override HashCode and Equals?  RSS feed

 
Raza Mohd
Ranch Hand
Posts: 247
Java MyEclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all,

i want to know that what is the reason we override Equals Method in our Java class with HashCode.

Is there any specific requirement..??''

Can anybody please let me aware of this..

Thanks n Regards
raza.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1) Override equals when your class models some sort of type in which different instances can be considered equal, depending on the values they have.
2) Override hashCode when you override equals, and only if you override equals.
 
Raza Mohd
Ranch Hand
Posts: 247
Java MyEclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi

Thanks for reply??

What will be the cases When it will happen..

Can you please provide any example..

Thanks...
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
http://www.coderanch.com/t/514972/java/java/Explation-Object-Identity#2330779
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a nice explanation from Stephan van Hulst.
When should you override those two methods? It is more a case of when should you not override them? The default is you ought to override hashCode, equals and toString unless you can think of a good reason why those overridings are not required.
 
Raza Mohd
Ranch Hand
Posts: 247
Java MyEclipse IDE MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks stephan ...
it was really nice example..
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:That's a nice explanation from Stephan van Hulst.
When should you override those two methods? It is more a case of when should you not override them? The default is you ought to override hashCode, equals and toString unless you can think of a good reason why those overridings are not required.

While I agree that you should override them more often than not, I would like to add that in fact you generally *can't* override them when extending another class that overrides them, because this will break the parent.

Let's extend Book:
Thanks to the introduction of this class, Book is now broken, because its equals and hashCode methods do not agree with the contract.

Therefore, I believe that classes that override equals and hashCode should either be final, or the equals and hashCode methods should be declared final.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ummmm this of course goes only for equals and hashCode

Override toString as often as possible!
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's the danger of using instanceof. That can be used in only two cases: 1) the class is final, or 2) the equals method is final. In all other cases I prefer to test for class equality:
This way both statements will print false.
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Prime wrote: . . . instanceof. . . .
Damn! Rob has beaten me to it again. Do a search for Effective Java by Joshua Bloch or Angelika Langer Java equals hashCode or the link Garrett Rowe gave me in this post.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that comparing classes works from a contract point of view. However, as Effective Java says it violates the Liskov Substitution Principle:

You may hear it said that you can extend an instantiable class and add a value component while preserving the equals contract by using a getClass test in place of the instanceof test in the equals method:

[...]

This has the effect of equating objects only if they have the same implementation class. While this may not seem so bad, the consequences are unacceptable.


So I prefer to use instanceof, and declare the methods final. (Usually I don't, because most of the classes I write that override these methods are already declared final).
 
Rajkamal Pillai
Ranch Hand
Posts: 445
1
Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I agree wholeheartedly with each and every one of the earlier posters! But if I would like to add and be corrected, if the more experienced professionals differ in opinion....

Going back to the original question, I feel that object comparison is JVM specific? For instance, for comparing two objects, a particular JVM could probably use the hashCode() and another could use just the equals()? I feel Mr. James Gosling and team laid out this contract cause otherwise it could possibly result in entirely different, if not opposite, results, on different environments? And this I feel would result in the same program/application exhibiting different behavior in different environments (Which would beat the purpose)?

Cheers,
Raj.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:I agree that comparing classes works from a contract point of view. However, as Effective Java says it violates the Liskov Substitution Principle:

Using instanceof may break the contract of Object.equals, using getClass() breaks the LSP. Darned if you do, darned if you don't. The only safe way is to make it impossible to override the method.
 
Campbell Ritchie
Marshal
Posts: 56584
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raj Kamal wrote: . . . I feel that object comparison is JVM specific? . . .
No, it isn't. You could easily write code which uses the hash code instead of equals() but that is by no means JVM-specific.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!