[hashCode]two meaningfully equal objects in one bucket

[Roy Miro]

Hello all,

It is my first post on this forum.
I'm preparing for the scjp exam with Kathy Sierra and Bert Bates' book.
Before, i have been reading you for a while.


with this given code:

public class Dolphin {
	
	String name;
	public Dolphin(){}
	
	public Dolphin(String n){
		name=n;
	}
	public boolean equals(Object o){
		if((o instanceof Dolphin) && (((Dolphin)o).name == name)){
			return true;
		}
		return false;
	}
	
	public int hashCode(){return name.length();}
}    

import java.util.HashMap;
import java.util.Map;

public class HashMapTest {

	public static void main(String[]args){
		Map<Dolphin, String> map = new HashMap<Dolphin, String>();
		
		Dolphin d1 = new Dolphin("UN");
		Dolphin d2 = new Dolphin("DEUX");
		
		System.out.println(d1.name+" (hashcode: "+d1.hashCode()+")  _  "+d2.name+" (hashcode: "+d2.hashCode()+")");
		
		map.put(d2,"Dolphin 2");
		map.put(d1,"Dolphin 1");
		
		System.out.println("map size: "+map.size());
		d2.name = d1.name; // renaming
		System.out.println(d1.name+" (hashcode: "+d1.hashCode()+")  _  "+d2.name+" (hashcode: "+d2.hashCode()+")");
		System.out.println("map size: "+map.size());
		
		System.out.println(map.get(new Dolphin("UN")));
if(new Dolphin("UN").equals(d1) && new Dolphin("UN").equals(d2)){
			System.out.println("Both meaningfully equal");
		}
		
	}
}   

I get this console output:

UN (hashcode: 2) _ DEUX (hashcode: 4)
map size: 2
UN (hashcode: 2) _ UN (hashcode: 2)
map size: 2
Dolphin 1
Both meaningfully equal

My question is:
after the renaming (both dolphins are named "UN"), both dolphins are in the same "bucket" (thanks to the hashCode method, as you can see their hashcode value is 2) and both are "meaningfully equals" to the dolphin created I passed to map.get(...) to perform the search:

  System.out.println(map.get(new Dolphin("UN")));  

Why does map.get(new Dolphin("UN")) return the dolphin previouly referenced by d1 and why not the one referenced by d2?
(in the console output, i get "Dolphin 1"...) while d1 and d2 succeed the equal test after the renaming?

Thank you for your help and time!
Please don't hesitate to solicit me if something isn't clear.

[Abimaran Kugathasan]

Roy Miro wrote:
both dolphins are in the same "bucket"

How do you conclude this? HashMap don't allow duplicates. And still your HashMap's size is 2. When you create the HashMap, it will create hash buckets. How do you tell, that, they are in same bucket? They story is different!~

[Abimaran Kugathasan]

And, Welcome to JavaRanch!

[pete stein]

You've got a problem with your equals method:

	public boolean equals(Object o){
		if((o instanceof Dolphin) && (((Dolphin)o).name == name)){
			return true;
		}
		return false;
	}

You'll want to compare the name strings via the equals method not via the == operator.

[Sven Mathijssen]

pete stein wrote:You've got a problem with your equals method:

	public boolean equals(Object o){
		if((o instanceof Dolphin) && (((Dolphin)o).name == name)){
			return true;
		}
		return false;
	}

You'll want to compare the name strings via the equals method not via the == operator.

Athough I agree with you in always comparing through the equals method, in this case it shouldn't matter because two Strings are compared from the String constant pool, returning true for the compared Strings, right?

[Abimaran Kugathasan]

Sven Mathijssen wrote:
Athough I agree with you in always comparing through the equals method, in this case it shouldn't matter because two Strings are compared from the String constant pool, returning true for the compared Strings, right?

Exactly, I think, the story is different. There are two hashcode buckets, and those objects are in different buckets. So, even with the == opetator, the HashMap size 2.

[pete stein]

Sven Mathijssen wrote:
Athough I agree with you in always comparing through the equals method, in this case it shouldn't matter because two Strings are compared from the String constant pool, returning true for the compared Strings, right?

I don't believe that it's guaranteed to be the same String only that it is likely to be the same String object. For instance if the String is created using the new String(...) constructor then it is usually a different object.

The key to the problem here though is that the OP's code corrupts the HashMap as keys are not supposed to be changed once used.

[Sven Mathijssen]

Abimaran Kugathasan wrote:

Sven Mathijssen wrote:
Athough I agree with you in always comparing through the equals method, in this case it shouldn't matter because two Strings are compared from the String constant pool, returning true for the compared Strings, right?

Exactly, I think, the story is different. There are two hashcode buckets, and those objects are in different buckets. So, even with the == opetator, the HashMap size 2.

This makes an interesting case. What happens when a key is already in a collection and after a change to the object, the object is equal to another object already used as a key in the Collection.

From [1]:

If an object's hashCode() value can change based on its state, then we must be careful when using such objects as keys in hash-based collections to ensure that we don't allow their state to change when they are being used as hash keys. All hash-based collections assume that an object's hash value does not change while it is in use as a key in the collection. If a key's hash code were to change while it was in a collection, some unpredictable and confusing consequences could follow. This is usually not a problem in practice -- it is not common practice to use a mutable object like a List as a key in a HashMap.

[1] http://www.ibm.com/developerworks/java/library/j-jtp05273.html

[Sven Mathijssen]

pete stein wrote:

Sven Mathijssen wrote:
Athough I agree with you in always comparing through the equals method, in this case it shouldn't matter because two Strings are compared from the String constant pool, returning true for the compared Strings, right?

The key to the problem here though is that the OP's code corrupts the HashMap as keys are not supposed to be changed once used.

Ah, there is the 'key' to the real problem ;) You are violating Map's contract here:

From [2]

Note: great care must be exercised if mutable objects are used as map keys. The behavior of a map is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is a key in the map

[2] http://cupi2.uniandes.edu.co/site/images/recursos/javadoc/j2se/1.5.0/docs/api/java/util/Map.html

[Abimaran Kugathasan]

Genuine Search Sven Mathijssen!

[Abimaran Kugathasan]

Have a look on this. Similar topic!

[Roy Miro]

After reading your replies, i conclude that:

1. Once a object is put in a bucket it cannot change for an other bucket even if the object's hashCode change (that's why the map size remains 2 in my example).
2. According to Sven Mathijssen links, although technically possible, a key object isn't due to have its state change. Otherwise, the map behavior isn't predictable.

Please confirm that my comprehension is correct.

Thanks a lot for your answers and impressive reactivity.

[Shanky Sohar]

if you try to change the value after once put in a hashmap then hashmap will be corrupted.

[Divyeshh Patel]

Roy Miro wrote:After reading your replies, i conclude that:

1. Once a object is put in a bucket it cannot change for an other bucket even if the object's hashCode change (that's why the map size remains 2 in my example).
2. According to Sven Mathijssen links, although technically possible, a key object isn't due to have its state change. Otherwise, the map behavior isn't predictable.

Please confirm that my comprehension is correct.

Thanks a lot for your answers and impressive reactivity.

Yes Roy, you have understood it correctly.

[Roy Miro]

Ok,
thank you all!