aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Doubt in Collections Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Doubt in Collections " Watch "Doubt in Collections " New topic
Author

Doubt in Collections

vedagni tula
Greenhorn

Joined: Oct 11, 2008
Posts: 21
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

Joined: Nov 07, 2008
Posts: 488
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.


SCJA
~Currently preparing for SCJP6
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18845
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
vedagni tula
Greenhorn

Joined: Oct 11, 2008
Posts: 21
Wow.. That's really cool.
Thanks much Henry. I got the concept now.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Doubt in Collections