File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes about map (HashMap to be specific) 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 » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "about map (HashMap to be specific)" Watch "about map (HashMap to be specific)" New topic

about map (HashMap to be specific)

Bert Bumper

Joined: Feb 06, 2011
Posts: 9
i'm really lost what happened here


Object Key Test

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

Joined: Apr 06, 2010
Posts: 4544

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

Joined: Sep 20, 2010
Posts: 4642

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.

The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Bert Bumper

Joined: Feb 06, 2011
Posts: 9
thanks for the help guys, I've really missed that part
Anayonkar Shivalkar

Joined: Dec 08, 2010
Posts: 1545

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)

Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
I agree. Here's the link:
subject: about map (HashMap to be specific)
It's not a secret anymore!