Map objects breaking equals() and hashCode() contract

[Astha Sharma]

Question from enthuware mock test-

import java.util.*;
public class Info
{
	String s1, s2, s3;
	public Info(String a, String b, String c)
	{
		s1=a; s2=b; s3=c;
	}
	public boolean equals(Object obj)
	{
		if(! (obj instanceof Info) ) return false;
		Info i = (Info) obj;
		return (s1+s2+s3).equals(i.s1+i.s2+i.s3);
	}
	public int hashCode()
	{
		return s1.hashCode();
	}
	public static void main(String[] args)
	{
		HashMap map = new HashMap();
		Info i1 = new Info("aaa", "aaa", "aaa");
		Info i2 = new Info("aaa", "bbb", "ccc");
		map.put(i1, "hello"); //1
		map.put(i2, "world"); //2
	}
}

Correct statement-
"Both the objects will be stored in the HashMap however retrieving them using the Info objects as keys will not be possible."

Explanation

In this particular case, since the keys (i.e. the two Info objects) are unequal as per their equals() method and even though their hashcode are same, the HashMap will work properly for them. Both the objects will be stored and retrieved. However, the retrieval will fail only for Info objects that break the rule of equals() and hashCode() are put in the map.

Here I don't understand the line written in bold. What does it mean? It would be great if anyone can give some example of Info objects breaking rule of equals() and hashCode().

[Andrea Binello]

Astha Sharma wrote:Correct statement-
"Both the objects will be stored in the HashMap however retrieving them using the Info objects as keys will not be possible."

This is not correct. In the Info class the contract between equals and hashCode is correct. This doesn't mean that the implementation of equals/hashCode is good or "optimum". But only that they doesn't break the contract.

If you execute map.get(i1) you get "hello" and with map.get(i2) you get "world".

Note that the concatenation of strings in equals is not a very intelligent thing to do (it is better to compare each field)

[Sidharth Khattri]

Astha Sharma wrote:Question from enthuware mock test-

import java.util.*;
public class Info
{
	String s1, s2, s3;
	public Info(String a, String b, String c)
	{
		s1=a; s2=b; s3=c;
	}
	public boolean equals(Object obj)
	{
		if(! (obj instanceof Info) ) return false;
		Info i = (Info) obj;
		return (s1+s2+s3).equals(i.s1+i.s2+i.s3);
	}
	public int hashCode()
	{
		return s1.hashCode();
	}
	public static void main(String[] args)
	{
		HashMap map = new HashMap();
		Info i1 = new Info("aaa", "aaa", "aaa");
		Info i2 = new Info("aaa", "bbb", "ccc");
		map.put(i1, "hello"); //1
		map.put(i2, "world"); //2
	}
}

Correct statement-
"Both the objects will be stored in the HashMap however retrieving them using the Info objects as keys will not be possible."

Explanation

In this particular case, since the keys (i.e. the two Info objects) are unequal as per their equals() method and even though their hashcode are same, the HashMap will work properly for them. Both the objects will be stored and retrieved. However, the retrieval will fail only for Info objects that break the rule of equals() and hashCode() are put in the map.

Here I don't understand the line written in bold. What does it mean? It would be great if anyone can give some example of Info objects breaking rule of equals() and hashCode().

when i1 is put as a key in the HashMap, the hashCode is calculated as per the string "aaa".
Now when i2 is put as a key in the HashMap, the hashCode will be calculated as per the string "aaa" again, so they'll go in the same bucket, but will be two different objects, because the equals return false when "aaaaaaaaa" is compared with "aaabbbccc". So both i1 and i2 key-value pairs are added to the map.
Now if you'll try to retrieve i1 by using map.get(i1), hashcode for i1 here will be checked with the hashcode of i1 already added to the map, which will be same, so the equals will kick in and "aaaaaaaaa" of i1 from get method's argument will be equals to the "aaaaaaaaa" in the i1 of the map, and the value returned will be "hello". Same for i2.

[Dan Drillich]

About Question com.enthuware.ets.scjp.v6.2.711 can help...

Regards,
Dan

[Himai Minh]

Astha,
This is the equals and hash code contract:
1. If two objects have the same hash code, they may or may not be equal.
2. If two objects have different hash codes, they are not equal.
3. If the hash codes of two objects are different, the two objects are not equal.
4. If the hash code of two objects are the same, the two objects may or may not be equal.

Analogy:
We have 10 buckets with a number on each of them : 1, 2, 3 ...10
1. If two balls (red and blue balls) are put in bucket 1, they have the same bucket number (hash code), but they are different balls.
2. If two balls (red and blue balls) are put in bucket 2 and 3, they have different bucket numbers (hash codes), and they are two different balls.
3. If you are looking for a red ball in bucket 1, then you find a red ball. This red ball is the one you are looking for.
4. If you are looking for a ball in bucket 1, you find a red and blue ball. But they are different balls.

[Henry Wong]

Himai Minh wrote:Astha,
This is the equals and hash code contract:
1. If two objects have the same hash code, they may or may not be equal.
2. If two objects have different hash codes, they are not equal.
3. If the hash codes of two objects are different, the two objects are not equal.
4. If the hash code of two objects are the same, the two objects may or may not be equal.

Analogy:
We have 10 buckets with a number on each of them : 1, 2, 3 ...10
1. If two balls (red and blue balls) are put in bucket 1, they have the same bucket number (hash code), but they are different balls.
2. If two balls (red and blue balls) are put in bucket 2 and 3, they have different bucket numbers (hash codes), and they are two different balls.
3. If you are looking for a red ball in bucket 1, then you find a red ball. This red ball is the one you are looking for.
4. If you are looking for a ball in bucket 1, you find a red and blue ball. But they are different balls.

Keep in mind that hashing algorithms has a concept of "bucket". So, many times, the discussion of the implementation of hashing talks about buckets. And hash codes and the number of buckets do *not* have a one to one relationship.

In your analogy, you are using the term "bucket" literally. And it (seemingly) does have a direct (one to one) relationship to hash code. Perhaps, this analogy may cause more confusion than good?

Henry

[Himai Minh]

I believe understanding hash table is important to understand the equals/hashcode contract.
A hash table is a 2D table with indices, like table[0], table[1], table[2].....
Each index (0,1,2,3... ) is a hash number. Each table entry is analogy to a bucket. Objects in a table entry, say table[0], share the same hash code, but they are different objects.

[timo corn]

I would rather say that the first index(table[first][second] of a twodimensional table is like buckets.Attributes of objects inside these buckets can be similar if they are in the same bucket(same "row") and the equals Methods delivers "true".