Hashtable.Entry.hashCode() no longer conforms to Map.Entry.hashCode()

Neil Richards neil.richards at ngmr.net
Tue Oct 16 01:29:49 UTC 2012

I notice that the behaviour of java.util.Hashtable.Entry.hashCode() no
longer conforms to the defined behaviour (in the Java API Javadoc [1])
for java.util.Map.Entry.hashCode() implementations.

The code in Hashtable.Entry.hashCode() assumes that the value in
Hashtable.Entry.hash will always be the same as that for
Hashtable.Entry.getKey().hashCode() .

However, since Java bug 7126277 (Alternative String hashing
implementation), the use of Hashtable.hashSeed, a randomizing factor,
has been introduced into the calculation of Hashtable.hash().

It is the result from Hashtable.hash() which ends up stored in the
Hashtable.Entry.hash field.

So the assumption made in Hashtable.Entry.hashCode() is no longer valid,
and the code needs to be corrected, so that it once more complies with
the Java API defined behaviour.

I have created a webrev [2] with my suggested fix for this problem,
together with a simple testcase to demonstrate it.

(I've also checked the other Map implementations modified by 7126277,
and verified that the others still conform to the Java API in this

Please review the problem and suggested fix, and let me know your

I am not aware of an existing Java bug for this issue. 
Provided you agree with my analysis, could one be raised to allow the
fix to be committed?


[1] http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode%28%29
[2] http://cr.openjdk.java.net/~ngmr/hashtable-entry-hashcode-fix/webrev.00

Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

More information about the core-libs-dev mailing list