aspose file tools*
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 Soft Skills 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
Author

about map (HashMap to be specific)

Bert Bumper
Greenhorn

Joined: Feb 06, 2011
Posts: 9
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

Joined: Apr 06, 2010
Posts: 4489
    
    8

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

Joined: Sep 20, 2010
Posts: 3649
    
  17

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

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

Joined: Dec 08, 2010
Posts: 1512
    
    5

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)


Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: about map (HashMap to be specific)