JDK-8050217 : Enum.hashCode() should return ordinal value for the enum, for better consistency
  • Type: Enhancement
  • Component: core-libs
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • Submitted: 2013-03-06
  • Updated: 2022-08-10
  • Resolved: 2015-02-19
Related Reports
Relates :  
JDK-8252556 - deepHashCode may be improved to generate consistent hash code
Relates :  
JDK-7190798 - java enum hashcode not stable among JDK 7
Description
A DESCRIPTION OF THE REQUEST :
I discovered, that java.lang.Enum.hashCode() returns default hashCode value.

It does not contradict with JLS, but it would be more consistent to return Enum.ordinal() as hashCode() value which is unique, by it's definition.

JUSTIFICATION :
It does not contradict with JLS, but it would be more consistent to return Enum.ordinal() as hashCode() value which is unique, by it's definition.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Enum.hashCode() should return Enum.ordinal() value
ACTUAL -
Enum.hashCode() returns default Object.hashCode() value
Comments
An alternative suggested by JDK-8252556 is to use the hashCode() of the enum constant's name instead of its ordinal. Unclear whether this is any better. Ordinal values are unique within an enum type, so they're probably as collision-resistant as possible already. A rationale stated in JDK-8252556 for this is "a consistent hash code is almost strictly required by cache key generator implementations." The implicit requirement here is that the hash code be consistent from one run of the JVM to the next and also presumably across JDK implementations. I find this remotely plausible but not compelling. Using an object's hashCode for purposes outside the JVM seems to be crossing outside its intended use. As noted, Object.hashCode() already states, "This integer need not remain consistent from one execution of an application to another execution of the same application." Of course, this could be overridden for enum constants, as it already is for other classes that have have tightly specified hashCodes, such as String and the boxed primitives. The question is whether this is worth doing. ** After some discussion, we felt that there is still no compelling reason to guarantee consistent hash codes. There is some sentiment that the tightly-defined hashCode for String was a mistake, for example (and also possibly for the boxed primitives). Adding a tight specification for another type could be viewed as a step in the wrong direction. In addition, there are some compatibility issues to be considered. How stable do the hashCodes need to be? For example, if an enum constant is added, it might affect the ordinals of existing enum constants. Is that a problem? Given that there are a fair number of design decisions to be made, and still no compelling reason to make the change, it doesn't seem worthwhile to pursue this. Therefore, I'm leaving this issue closed.
04-09-2020
There is some risk of behavioral incompatibility in changing the hash codes of enum constants, as their hash codes have been the default hashCode (System.identityHashCode) since their introduction in Java SE 5 (2004). There is also no benefit demonstrated to changing the hash codes to match the ordinal values. Therefore, I'm closing this as Won't Fix.
19-02-2015