JDK-8000955 : Hashtable.Entry.hashCode() no longer conforms to Map.Entry.hashCode()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 7-pool,8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-10-16
  • Updated: 2013-06-26
  • Resolved: 2012-10-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u40Fixed 8 b63Fixed
Neil Richards <neil.richards@ngmr.net> reports:

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.
Test: java/util/Map/EntryHashCode.java

See also the OpenJDK core-libs thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-October/011842.html