I've just realised
k.hashCode() = key.hashCode()
k == key
k is "equivalent" to key
k must be == to key
So, it's regardless whether
kis "equivalent" to
No, that is incorrect, as @KevinWallis already observed.
hashCode() to identify the correct hash bucket, and
==, to compare keys that fall into the same bucket. Types that have a meaningful sense in which distinct instances are equivalent are supposed to describe that via their
equals() methods, and standard library types such as
Integer in fact do so. When the keys are of such a type, you do not have to use the same object to retrieve a value from a
HashMap that you did to store it.
On the other hand, types that do not have a meaningful sense in which distinct instances are equivalent should not, and generally do not, override
hashCode()). The implementation inherited from
Object yields the same result as the
== operator, which makes it possible and sensible to use such objects as
HashMap keys or to store them in
HashSets, at least under some circumstances.
Is it possible to change this behaviour in order to use only hashCode() equivalence?
It is not possible to change the behavior of
HashMap in this regard. If you were able to do so then the resulting map would not correctly fulfill the
Map contract. You can, however, implement your own map-like class that behaves as you describe, or you can create a wrapper class to use as a substitute key type.