This week's book giveaway is in the Design forum.
We're giving away four copies of Design for the Mind and have Victor S. Yocco on-line!
See this thread for details.
Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hashcode & equals - stop me before someone gets hurt!

 
Chris Perkins
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've come across a situation where it seems like it would be useful to define my class's "equals" method to return true in certain cases where the two objects in question return different hashcodes.
The problem is that there is a little voice in the back of my head telling me that this is a very bad idea - but I can't think of a specific, concrete reason why it is a bad idea. Can anyone set me straight?
Chris
P.S.: I can be more specific about the class I'm writing (i.e. include code), if anyone needs details.
 
Cindy Glass
"The Hood"
Sheriff
Posts: 8521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The hashcodes are guaranteed to be the same if the inputs are the same. However, it is possible for two different objects to hash to the same result (depending on the algorithm used to hash) - hashing is not guaranteed to be unique. So using it as an equals identifier would not be a good idea.
 
Mark Herschberg
Sheriff
Posts: 6037
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter Hagger covers this topic in good detail in his book Practical Java* He devotes about 35 pages to the topic of equality in Java. I would recommend going to a book store to check it out, then realize how valuable a book it is, and go buy it. :-)
The best part is, you get free "technical support" for the book because Peter is one of our Bartenders.
--Mark

*Book info can be found at the Bunkhouse http://www.javaranch.com/bunkhouse/bunkhouseAdvanced.jsp
 
John Dale
Ranch Hand
Posts: 399
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The little voice you hear may be your memory of reading the Java API documentation.
hashcode() must conform the contract for that operation in the class Object, since your class extends Object. If you look at the Java API documenation for Object's hashcode methods, you will see that if two objects are equal according to equals(Object), then they must have the same value for hashcode().
Of course, there is nothing to prevent you from defining your own specialHashcode() method for your own purposes that don't require consistency with equals().
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On a more practical level: because consistency between equals() and hashCode() (and, if defined, compareTo()) is required in the contract for java.lang.Object (resp. Comparable), any class you're using may be implicitly relying on it. The most common examples are the Collections classes. If equals() and hashCode() are not mutually consistent, then neither HashMap nor HashSet will work correctly with your objects, nor will any class that uses them under the hood (and you may not necessarily be aware of this!)
- Peter

[This message has been edited by Peter den Haan (edited October 18, 2001).]
 
walter wang
Ranch Hand
Posts: 159
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if object is different then hashcode will also be different
in another words hahscode is indentical just like ID.
u mean you want to write a method to compare different objects
then..still return true?
i think you could compare their fields..just assuming
obj1 and obj2 only have 2 fields int and string
eg obj1 !=obj2;
but if ((obj1.string.equals(obj2.string))
&&(obj1.int==obj2.int))
return true;
else
return false;

Originally posted by Chris Perkins:
I've come across a situation where it seems like it would be useful to define my class's "equals" method to return true in certain cases where the two objects in question return different hashcodes.
The problem is that there is a little voice in the back of my head telling me that this is a very bad idea - but I can't think of a specific, concrete reason why it is a bad idea. Can anyone set me straight?
Chris
P.S.: I can be more specific about the class I'm writing (i.e. include code), if anyone needs details.

 
John Dale
Ranch Hand
Posts: 399
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is permissable to have objects that are not equal according to equal(Object) return the same hashcode(). See the API documentation for the hashcode() method of Object for the requirements on all hashcode() methods.
 
Chris Perkins
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to everyone for the replies - after a good night's sleep and some vitamin C
  • , the little voice in my head is speaking plain English again.
    It was, of course, a very bad idea I had. I had somehow convinced myself that a simple String wrapper class I had should compare as equal to a String the same as the wrapped String ( make sense? ), for retrieval from a HashMap. I missed the obvious point that I would be looking in the wrong hash bucket, so the comparison would never happen.
    Chris
    Footnote: vitamin C == caffeine
  •  
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic