File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Hashcode & equals - stop me before someone gets hurt! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Hashcode & equals - stop me before someone gets hurt!" Watch "Hashcode & equals - stop me before someone gets hurt!" New topic
Author

Hashcode & equals - stop me before someone gets hurt!

Chris Perkins
Greenhorn

Joined: Mar 26, 2001
Posts: 9
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

Joined: Sep 29, 2000
Posts: 8521
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.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
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

Joined: Feb 22, 2001
Posts: 399
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

Joined: Apr 20, 2000
Posts: 3252
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

Joined: Jun 02, 2001
Posts: 156
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.


public class Walter { public boolean is_Working_Now (boolean is_boss_Coming) { return is_boss_Coming; }
John Dale
Ranch Hand

Joined: Feb 22, 2001
Posts: 399
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

Joined: Mar 26, 2001
Posts: 9
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
  •  
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Hashcode & equals - stop me before someone gets hurt!