• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

about map (HashMap to be specific)

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i'm really lost what happened here


OUTPUT:

null
Object Key Test
null

the output is the same with the K & B book what I don't under stand is at line 16 the object referenced by keyMine was modified, the same object used as a key in the map. if that is the same object then changing its field (specifically its name) should have also affected the object set as the key in the map.

i'm wondering what am I missing?

thanks in advance
 
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It will change the object used as a key. But what you're missing is the way HashMap works.

A HashMap will put values into buckets based on the hash code. You've then changes the key - which changed the hash code. Which means that the HashMap no longer has the value stored in the right place. When it looks for it it will look in the wrong bucket and so not find anything. And so it returns null.

I haven't tried it, but if you change the implementation of hashCode() so that the value won't be changed (just returning a constant will do) the behaviour should change.
 
Bartender
Posts: 15737
368
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I assume you mean that you're wondering why it returns null even if the key in the map also changed?

The reason has to do with the way hash tables work. They store key-value pairs in different lists according to the hash code of the key. When you put the key with the name "fine" in the map, it will be stored in the list that accords with the hash code 4. When you change the key's name, it's hash code changes to 8. So then when you try to get the value that belongs to that key, the hash table will look in the list that accords with the value 8, and it will find nothing.

This is why it's a bad idea to use mutable objects as keys in a hash map. You should always use immutable objects, like Strings, Integers, enums (EnumMap!), or your own immutable types.
 
Bert Bumper
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the help guys, I've really missed that part
 
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bert,

This is a classic example of Java coding practices.

Most of the books/texts only mention that to implement a HashMap successfully, all you need to do is: implement equals and hashCode method.

Further to this, it is recommended that in HashMap, key should be immutable (e.g String, Integer etc.). Now you know why.
(If key is not immutable, it can be accidentally/intentionally modified outside HashMap and then the value becomes inaccessible)
 
Wait for it ... wait .... wait .... NOW! Pafiffle! A perfect tiny ad!
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic