Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Doubt in Collections

 
vedagni tula
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Given: (Source is from sun epractice exams)

1. class Sock {
2. String size;
3. String color;
4. public boolean equals(Object o) {
5. Sock s = (Sock) o;
6. return size.equals(s.size) && color.equals(s.color);
7. }
8. }

Which two are true? (Choose two.)

A Two instances of Sock with the same size and color will have the same hashcode.
B Two instances of Sock with the same size and color might have different hashcodes.
C A Hashtable that uses Sock instances as keys will always be able to successfully retrieve objects stored in it.
D A Hashtable that uses Sock instances as keys will NOT always be able to successfully retrieve objects stored in it.

Answer is B and D

How can we make this conclusion?

What does the equals method in the above class trying to convey? - When we compare two sock objects with equals method, then this overridden equals method return true only if both objects have same size and color... Does it mean the same or am i missing something?

If both objects are equal, then whynot same hashcode. Is it because we didnot override hashcode() method? How will the compiler reacts to this case?

Please let me understand what i am missing in this question to make the conclusion.
 
Brian Legg
Ranch Hand
Posts: 488
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wish I could help you more but I am a bit confused when it comes to equals() and hashCode() as well. I do know that before they called the "Sock s = (Sock) o;" line they should have used the instanceof operator to make sure the Object was in fact a Sock. The Objects come in polymorphically so if you don't test them you can get a ClassCastException.

If I had to take a guess though, I would say it is the lack of overriding the hashCode() method or the fact that Strings are immutable that is causing the unexpected answer.
 
Henry Wong
author
Marshal
Pie
Posts: 21504
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If both objects are equal, then whynot same hashcode. Is it because we didnot override hashcode() method? How will the compiler reacts to this case?


The hashCode() method has not been overridden, so the hashCode() method from the Object class will be used. This hashcode method returns a hashcode based on an equals() method that checks for reference equality (the equals() method of the Object class) -- two objects are considered equal only if they are the same object.

A Two instances of Sock with the same size and color will have the same hashcode.


Well, if you have two different Sock objects, chances are the hashcode are different, since the Object hashcode method is based on reference equality... so this is not true.

B Two instances of Sock with the same size and color might have different hashcodes.


See choice A explanation for why this is true.

C A Hashtable that uses Sock instances as keys will always be able to successfully retrieve objects stored in it.


A class whose equals() method says they are equal, while the hashCode() method returns two different hashcodes, is a violation of the equals()/hashCode() contract... And will break the hashing container. It is not guaranteed to work correctly. So, this is not true.

D A Hashtable that uses Sock instances as keys will NOT always be able to successfully retrieve objects stored in it.


See choice C explanation for why this is true.


Henry
 
vedagni tula
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow.. That's really cool.
Thanks much Henry. I got the concept now.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic