No, they are not correct Abhi. The way to think about the three relationships (hashCode() values, equals() return, and == return) is:
The most strict (specific) relationship is ==. If == is true, you can be assured that if the implementations of equals and hashCode are correct, equals will return true, and the hashCode values will be the same.
The next relationship in order of strictness is equals. If equals is true, you must have that hashCode values are the same.
Finally, you have hashCode. This is the least strict relationship. Even for completely unrelated objects of the same class, hashCode may return the same values.
Let me know if that makes sense, and try to reason why A and B are false.
All code in my posts, unless a source is explicitly mentioned, is my own.
Hope Ruben cleared your doubt, Just an example here
For option A: Even though the objects are meaningfully equal, there memory location is not same.
For option B: it says "x==y may be true.". If it is true then it MUST be equal.
Hope i am clear.
SCJP 6
Why to worry about things in which we dont have control, Why to worry about things in which we have control ! !
That makes perfect sense.
But while adding objects to a hash-based collection we say that if you override the equals() method and dont override the hashCode() then the 2 objects will be considered unequal or different.
So I was trying to figure out the answer that way.
Abhi vijay wrote:That makes perfect sense.
But while adding objects to a hash-based collection we say that if you override the equals() method and dont override the hashCode() then the 2 objects will be considered unequal or different.
So I was trying to figure out the answer that way.
Good, Hash based collections first matches hashCode of both objects , if both objects found in same bucket than only it will call equals(Object) method.
SCJP 6
It would give a normal human mental abilities to rival mine. To think it is just a tiny ad:
a bit of art, as a gift, that will fit in a stocking