El método hashCode () en la clase Enum es final y se define como super.hashCode (), lo que significa que devuelve un número basado en la dirección de la instancia, que es un número aleatorio de los programadores POV.

Definiéndolo p. comoordinal() ^ getClass().getName().hashCode() sería determinista en diferentes JVM. Incluso funcionaría un poco mejor, ya que los bits menos significativos "cambiarían tanto como sea posible", por ejemplo, para una enumeración que contiene hasta 16 elementos y un HashMap de tamaño 16, seguramente no habrá colisiones (seguro, usar un EnumMap es mejor, pero a veces no es posible, por ejemplo, no hay ConcurrentEnumMap). Con la definición actual no tienes esa garantía, ¿verdad?

Resumen de las respuestas.

UtilizandoObject.hashCode() se compara con un código hash más agradable como el anterior de la siguiente manera:

PROSsencillezCONTRASvelocidadmás colisiones (para cualquier tamaño de un HashMap)no determinismo, que se propaga a otros objetos haciéndolos inutilizables parasimulaciones deterministasComputación ETagcazando errores dependiendo, p. en unHashSet orden de iteración

Personalmente, prefiero el mejor código hash, pero en mi humilde opinión, ninguna razón pesa mucho, tal vez a excepción de la velocidad.

ACTUALIZAR

Tenía curiosidad sobre la velocidad y escribí unpunto de referencia con sorprendenteresultados. Por el precio de un solo campo por clase, puede obtener un código hash determinista que es casicuatro veces más rápido. Almacenar el código hash en cada campo sería aún más rápido, aunque insignificante.

La explicación de por qué el código hash estándar no es mucho más rápido es que no puede ser la dirección del objeto a medida que el GC mueve los objetos.

ACTUALIZACIÓN 2

Hay algunas cosas extrañaspasando con elhashCode Rendimiento en general. Cuando los entiendo, todavía queda la pregunta abierta, por quéSystem.identityHashCode (leer desde el encabezado del objeto) es mucho más lento que acceder a un campo de objeto normal.