Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

about map (HashMap to be specific)

 
Bert Bumper
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • 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
 
Matthew Brown
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
  • 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.
 
Stephan van Hulst
Bartender
Pie
Posts: 6113
72
  • Mark post as helpful
  • send pies
  • 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
  • Quote
  • Report post to moderator
thanks for the help guys, I've really missed that part
 
Anayonkar Shivalkar
Bartender
Posts: 1557
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • 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)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic