Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

A doubt in a phrase found in Hibernate Made Easy

 
Sidharth Pallai
Ranch Hand
Posts: 134
Hibernate Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Cameron McKenzie,

I have refered this about your book Hibernate Made Easy.I got stucked in a section titled Object Comparisons when i encountered a line that reads
By default, when you compare two instances using .equals(), the compiler simply compares the memory locations of the two instances, as opposed to comparing their actual property values. Since we have two separate instances, we end up having two separate memory locations, and a .equals() comparison returns false.

May be am wrong, but i have a doubt on it.I knew that equals() method of java.lang.Object compares content of instances rather than memory locations which is done by == operator.I would like to correct myself if am worng.
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sidharth,

You've managed to ask a question that touches on Hibernate, SCJP, Java in General, and perhaps even advanced topics, all in one post! That's awesome.

A .equals() comparison SHOULD compare properties of objects. So, one 2002 Red Dodge Viper, and another 2002 Red Dodge Viper are .equals to each other, because they're both 2002 Red Dodge Vipers. This is what we expect when we compare objects - are they basically the same object.

When we use ==, we essentially compare memory locations. So, is the Red Dodge Viper driving down the street, being driven by that strange character, actually MY Dodge Viper? That's the == comparison.

However, when we create new classes, if we do not override .equals, the JVM doesn't know which properties to use and compare when doing a .eqauls. So, what does the compiler do? Well, it essentially defaults to an == comparison. I mean, what else could it do? It can't guess.

This is a big problem with Hibernate if you don't override .equals, because Hibernate won't know when two objects are the same or not. So, you always need to override .equals with your objects. Well, actually, you don't always have to. There are times when your program will work just fine without doing it. But you are setting yourself up for potential problems if you don't.

And to mess things up even more, you also should override .hashcode when you override .equals.

Here's a great thread on the topic. It has more to do with the need to override .equals in Hibernate than what actually goes on under the covers in the JVM. It's a great tutorial:

hibernate.org: Equals and Hashcode and the Hibernate3 Session

Thanks for the great question. If you have anything specific about the book, feel free to message me through JavaRanch or the email address that was in the preamble to the book.

Kindest regards,

-Cameron McKenzie
 
Shikhar Madhok
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This was definitely my learning for the day.

Thanks guys
 
Sidharth Pallai
Ranch Hand
Posts: 134
Hibernate Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks McKenzie for the beautifull explanation about .equals() & == behaviour, its really awesome.
Till now i haven't read your book,but now am compelled to go through.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic