aspose file tools*
The moose likes Java in General and the fly likes HashMap and hashCode method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "HashMap and hashCode method" Watch "HashMap and hashCode method" New topic
Author

HashMap and hashCode method

Rolf Johansson
Ranch Hand

Joined: Feb 25, 2004
Posts: 32
Hi:
If I plan to use my class in a HashMap, such as:

Is it necessary for me to override the hashCode method?
- Rolf.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
It's not necessary - the default hashcodes are fine. The main reason you might want to override hashcode() is if you are also overriding equals().
James Swan
Ranch Hand

Joined: Jun 26, 2001
Posts: 403
I disagree, if you intend to use your class as a "key" for a HashMap then you should implement a sensible hashcode method:
consider this example:

When I try to use "k2" to retrieve the value from the map, I get back null (because the default hashcode is the object reference), also when I try to replace the value of "k1" in the map, an extra value is put (potential memory leak).
[ May 04, 2004: Message edited by: James Swan ]
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Er, if your point is that k1 and k2 are essentially the 'same thing', then you'll be overriding equals(), won't you? Overriding the hashcode() method without overriding equals() won't change the behavior of your example at all.
James Swan
Ranch Hand

Joined: Jun 26, 2001
Posts: 403
Heh, by disagreeing to what Warren said, I mean "add to" what he said
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
A short resume for this discussion (to avoid any confusion): first, decide if you want to override the equals() method for the class that will be used as a key in a hash-based collection. If yes, you must also override the hashCode() method. Otherwise, you don't need to do anything. For an excellent treatment of this subject, see Effective Java.
Rolf Johansson
Ranch Hand

Joined: Feb 25, 2004
Posts: 32
Warren is absolutely correct when he states:

Er, if your point is that k1 and k2 are essentially the 'same thing', then you'll be overriding equals(), won't you? Overriding the hashcode() method without overriding equals() won't change the behavior of your example at all.

When using class Tester as a key in a HashMap BOTH hashCode() and equals() need to be overriden. The following example works fine, but if I DO NOT override equals() null is returned when I "get" k2. get() is using equals() to see if the object I'm "getting" is in the HashMap. If Tester does not override equals(), Object's equals() is used abd returns false when k2 is specified in "get" since it is not the same object as k1, the object that we "put" in the HashMap.
Even though hashCode() returns the same value for the 2 objects (k1 & k2) equals() must be used during get() so equals() must be overriden in order for get() to operate correctly on different objects with the same values.

Stating that equals() and hashCode() should be overriden together is not just a guideline, but a requirement for using an object in a HashMap.
John Smith
Ranch Hand

Joined: Oct 08, 2001
Posts: 2937
When using class Tester as a key in a HashMap BOTH hashCode() and equals() need to be overriden.
Depends how you want to use class Tester. To state the above more precisely, you can either a)override both equals() and hashCode(), or you can b)override neither. Both options a) and b) are perfectly acceptable, but you must understand the difference. The problem with the code posted by James is that the object identity was used where the object logical equivalence was intended. It doesn't mean at all that overriding both equals() and hashCode() is a requirement or a preferred method. It really comes down to how you want to treat the object equivalence in the context of the problem that you are trying to solve.
Incidentally, the hashCode() method in the code above is suboptimal. For example, for two distinct keys Tester(1, "1", new Integer(32)) and Tester(2, "1", new Integer(1)) it will return the same hash code. While this doesn't violate the hashCode() contract, it will not help the performance. In the worst case scenario, all of the keys will end up in the same hash bucket, and the entire HashMap will degrade into a linked list.
[ May 05, 2004: Message edited by: Eugene Kononov ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: HashMap and hashCode method