• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Map objects breaking equals() and hashCode() contract

 
Ranch Hand
Posts: 250
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Question from enthuware mock test-


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().
 
Ranch Hand
Posts: 62
5
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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)
 
Ranch Hand
Posts: 125
Scala Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Astha Sharma wrote:Question from enthuware mock test-


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.
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
About Question com.enthuware.ets.scjp.v6.2.711 can help...

Regards,
Dan
 
Ranch Foreman
Posts: 1924
13
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
author
Posts: 23879
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Foreman
Posts: 1924
13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 68
MyEclipse IDE PHP Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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".
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic