• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

HashMap and hashCode method

 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi:
If I plan to use my class in a HashMap, such as:

Is it necessary for me to override the hashCode method?
- Rolf.
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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().
 
Ranch Hand
Posts: 403
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 403
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Heh, by disagreeing to what Warren said, I mean "add to" what he said
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Space seems cool in the movies, but once you get out there, it is super boring. Now for a fascinating tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic