This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I found this question in the SCJP preparation guide book
Which statements are true about comparing two instances of the same class, given that the
equals() and hashCode() methods have been properly overridden? (Choose all that apply.)
A. If the equals() method returns true, the hashCode() comparison == might return false
B. If the equals() method returns false, the hashCode() comparison == might return true
C. If the hashCode() comparison == returns true, the equals() method must return true
D. If the hashCode() comparison == returns true, the equals() method might return true
E. If the hashCode() comparison != returns true, the equals() method might return true
and the wirtten answer is
"B and D. B is true because often two dissimilar objects can return the same hashcode
value. D is true because if the hashCode() comparison returns ==, the two objects might
or might not be equal.
A, C, and E are incorrect. C is incorrect because the hashCode() method is very flexible
in its return values, and often two dissimilar objects can return the same hash code value.
A and E are a negation of the hashCode() and equals() contract. (Objective 6.2)"
I couldn't get why "C" is incorrect while B and D are true
It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results.
So there can exist two unequal objects with the same hashCode.
So reversing this: even if two objects' hashCodes are equal, the objects might be unequal.
If they might be unequal it is not true that they must be equal ;).
Joined: Dec 18, 2013
Thank you Pawel in advance, could you explain to me what does he mean that the "hashcode" is properly overriden? and when 2 objects have the same Hashcode ?
AbdulRahman Mahmoud wrote:Thank you Pawel in advance, could you explain to me what does he mean that the "hashcode" is properly overriden? and when 2 objects have the same Hashcode ?
Properly overriden means according to contract of equals/hashCode which is described in those methods' javadoc.
Object#hashCode(), Object#equals(Object) Two object have the same hashcode when their hashCode() methods return the same int value.
For example, you are in a hotel. You want to find your girlfriend "Carrie", but she is in a room (number 9) with others friends of her "Maria" and "Alexandra".
The hashcode is like the number of the room. If you take the number 6, perhaps you will find a girl with the name Carrie, but it's not your friend. Otherwise, If you try to find someone in number 9, it's not sure that your friend is the first person that you meet (front of the door). But she's in the same room, it's sure.
So this is the reason why if two objects have the same hashcode, they may be equal, but it's not sure ! If you find the real Carrie, it means the hashcode and equals are true ! If you find an other "Carrie", the hashcode will be false, and because the hashcode is false, the equals is also false.
I hope you have a good understanding of my thinking.
Boyi Shen wrote:Why A&E are incorrect? We can override equals() method and make it just return true forever. There is none business with hashCode()? I mean hashCode might be different.
They are incorrect because that would violate the contract of equals/hashCode specified in java.lang.Object class.
The question does not ask if the language permits you to do that. The question asks if this is legal according to mentioned contract.