Looking up values from Map/HashMap when Objects are used as keys

Question

I'm trying to understand why Map/HashMap don't test for equals() when looking up a key ( which is an Object that overrides equals() and hashCode()) in the Map.
I've written this code, based on some code from the SCJP book, but it is not exactly the same, this code talks about a different issue not addressed in the book.
I've added my questions inside the comments below, I think that is the best way I can ask it.
import java.util.*;
class Bird{
     public String name;
     public Bird(String name){
          this.name = name;
     //Override equals()
     public boolean equals(Object o){
          if(((Bird)o).name.equals(this.name)){
               return true;
          }else{
               return false;
        //Override hashCode
     public int hashCode(){
          return name.length();
class TestMapLookup{
     static public void main(String[] args){
          Map<Object, Object> hashMap = new HashMap<Object, Object>();
          Bird b = new Bird("crow");
          hashMap.put(b, "somevalue");
          //according to the book, the map object calls the key's (Bird object's)
          //hashCode() first and then equals()
          //to find this key in the map
          System.out.println(hashMap.get(b));
          //Using the b reference to lookup value
          //ouputs - somevalue
          System.out.println(hashMap.get(new Bird("crow")));
          //Using a new Bird object to lookup value
          //outputs - somevalue
          //because Bird overrides equals and hashCode
          //otherwise we'd get null
          //Now change the name of the bird in the b reference
          b.name = "sparrow";
          //Notice that the crow's hashCode is 4
          //sparrow's hashCode is 7 , in the above implementation of hashCode
          System.out.println(hashMap.get(b));
          //Again using b reference to lookup value
          //ouputs - null
          //because the hashCode of b.name does not match
          //the hashCode of any of the keys stored in the map
          System.out.println(hashMap.get(new Bird("crow")));
          //This also outputs null
          //for the same reason that there's no key in the map
          //with a hashcode of 7
          //This is where it becomes strange......................
          //Change the name of the bird in the b reference
          //so that the new name has the same hashCode, as the key in the map
          b.name = "dove";
          System.out.println(hashMap.get(b));
          //In the above - the hashCode matches
          //but equals() fails
          //even though equals() fails, the key is still located and the value is output
          //output is "somevalue"
          //same here:
          b.name = "1234";
          System.out.println(hashMap.get(b));
          //output is "somevalue" instead of null
          b.name = "abcd";
          System.out.println(hashMap.get(b));
          //output is "somevalue" instead of null
          //why does it output "somevalue" instead of null , even though when the map
          //looks up the key , equals() returns false?     
          System.out.println(hashMap.get(new Bird("crow")));
          //In this case ( new Bird reference ) it prints null
}I'm aware of best practices in coding and coding conventions but haven't used them here, because this is in preparation for SCJP - which tests on a lot of different things.
I appreciate any info.

Answer 1

It is correct that b is referring to the same object that the map's key is pointing to, but why does the following
print null , instead of "somevalue"?
at these lines in the code above.
b.name = "sparrow";
System.out.println(hashMap.get(b));Because the hashCode used when you stored b was 4, and now it's 7. You should read the Wikipedia article on Hashtable, but a simplistic explanation is that a HashMap has a bunch of "buckets," say 10, each indexed with a number 0-9. To decide which bucket to put a new key-value pair in, you take the hashcode (say 2112) and take the remainder of hashcode/number of buckets (in this case, 2112%10=2). So when you store the key-value, it gets "put" in this bucket.
When you change the hashcode of b by changing its name attribute, it doesn't change the fact that the pair is in that bucket. But, it now looks in the wrong bucket and so can't find the pair.
A hashtable gets its good efficiency by not having to look through all values to find the pair. It can jump directly to the correct bucket, which takes constant time instead of being dependent on the number of items in the collection.
endasil wrote:
You should never, ever change an object being used as a key in a map.I guess this is a best practice, I just wanted to try changing the key object to test a few things for SCJP, which does not test on coding best practices but tests on how the code behaves.Yep, and what you should take away is that this is WHY it's bad to change the key :).