Effective Java - Chapter 3 - overriding hashCode when overriding equals(Object) method?

[honest cove]

Is there not even a thin possibility to get the PhoneNumber that has been put in the map? Let's suppose that the put instance and the get instance both return the same hashCode sdue to pigeon hole principle then it should be possible?

[covert kettle]

<@&987246924425994290> please have a look, thanks.

[stark grove]

Yes, that is possible, but these hash collisions are hard to achieve, and afaik not reproducible due to how Java works.
So yeah, once every ~4.3 billion (2³²) executions, that will work (if the equals function is properly overloaded)

[mellow epoch]

It's much likely than that
Firstly because the chance that each hashcode is taken isn't uniform (especially if you override it)
But most importantly, because hashmap does a hashcode % length, which means that chance that two item are in the same bucket are more likely by several order of magnitude @honest cove
It's not because of the hashcode that it returns null, it's because of equals. HashMap always check equals if they are in the same bucket

[stark grove]

the chance that each hashcode is taken isn't uniform
true, that improves the chances a tiny bit, let's say to 1 in 4 billion.

especially if you override it
the text specifically talks about the case where we don't override it, so that's irrelevant here

because hashmap does a hashcode % length, which means that chance that two item are in the same bucket are more likely by several order of magnitude
The text specifically talks about the hashmap caching certain hash values as an optimization, which it uses to check for equality first (only if the hashes match does it then check for .equals), so just being in the same bucket doesn't help at improving our 1 in 4 billion odds if the mentioned optimization is being used.