Cheers,
Prashant.
Cheers,
Prashant.
Matthew Brown wrote:The last one you are looking up with exactly the same key as it was added  the same object. So even the nonoverridden versions of equals() will return true and hashCode() will return the same value.
Cheers,
Prashant.
Cheers,
Prashant.
Jesper de Jong wrote:Remember the rule that hashCode() and equals() have to follow:
If two objects A and B are equal (calling A.equals(B) and B.equals(A) returns true), then their hash codes must be the same (A.hashCode() == B.hashCode()).
(If the equals() and hashCode() methods of the class of A and B don't follow that rule, then they are implemented incorrectly).
Note that the rule only works one way: it does not mean that if A and B are not equal, their hash codes must be different  they can still be the same.
Now, think about what it means. It means that if you have two objects A and B, and you compare their hash codes, and you find that their hash codes are different, then you can be sure that A and B are not equal. (Because if they are equal, their hash codes must be the same). So, HashMap doesn't always have to call equals() to know that two objects are different  when it sees that the hash codes are different, it already knows the objects are different, and it doesn't need to call equals().
Cheers,
Prashant.
No, you haven't. As long as you are using == on reference types that is incorrect.Prashant Mumbarkar wrote: . . .
now I have this correct version of equals method.
. . .
I think I'll just lie down here for a second. And ponder this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardenergift.com
