File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Java in General and the fly likes Custom Class as Key for Hash Map Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Custom Class as Key for Hash Map" Watch "Custom Class as Key for Hash Map" New topic

Custom Class as Key for Hash Map

Midhun Agnihotram

Joined: Feb 20, 2010
Posts: 11
Hi All,

We created a custom class to act as a key for HashMap as follows :

The CommonUtils.fieldChanged function is as follows :

When this class is used as a Key in HashMap and retrieve the value, I get a null - although in Debug mode I see the same key present in the HashMap too. I believe that this has got to do something with the equals / hashCode methods. Can anybody point to as what is wrong ?

Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 15100

To work correctly as a key in hash-based collections such as HashMap, your class must indeed have correctly implemented equals() and hashCode() methods. The documentation of the method hashCode() in class Object explains what the contract for this method is. The most important thing to remember from it is that if two objects are equal (i.e. equals() return true), then the hashCode() methods of both objects must return the same value.

In case of your code, the equals() and hashCode() methods seem to be OK - I don't see any obvious problems.

Maybe there is something else in your code, in the rest of the program somewhere, that causes the problem.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
James Sabre
Ranch Hand

Joined: Sep 07, 2004
Posts: 781

Any class being used as a key for a hash map should be immutable (at least as far as the hashcode() and equals() methods are concerned) since any change to a field that is used by either hashcode() or equals() will destroy the lookup of objects in the map. Since the fields in your class can be modified you don't have this property.

Retired horse trader.
 Note: double-underline links may be advertisements automatically added by this site and are probably not endorsed by me.
Costi Ciudatu
Ranch Hand

Joined: Oct 24, 2006
Posts: 74
The actual bug in your code is that you're calling hashCode() on the HashCodeBuilder (that class doesn't even overwrite the hashCode() method).
The proper usage of HashCodeBuilder is to call toHashCode() after setting it up:
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 15100

Good catch Costi, you're right!

But what James said is indeed also important. Objects that you use as keys in a HashMap must not be mutable, because if you modify the fields after you've put the object in the HashMap, so that the result of hashCode() changes, will confuse the HashMap, so that it can't find your objects anymore.
I agree. Here's the link:
subject: Custom Class as Key for Hash Map
It's not a secret anymore!