O método hashCode () na classe Enum é final e definido como super.hashCode (), o que significa que ele retorna um número com base no endereço da instância, que é um número aleatório dos programadores POV.

Definindo por ex. Comoordinal() ^ getClass().getName().hashCode() seria determinístico em diferentes JVMs. Até funcionaria um pouco melhor, já que os bits menos significativos "mudariam o máximo possível", por exemplo, para uma enumeração que contenha até 16 elementos e um HashMap de tamanho 16, haveria certamente nenhuma colisão (com certeza, usar um EnumMap é melhor, mas às vezes não é possível, por exemplo, não há ConcurrentEnumMap). Com a definição atual, você não tem essa garantia, tem?

Resumo das respostas

UsandoObject.hashCode() se compara a um hashCode mais agradável, como o descrito acima, da seguinte maneira:

PROSsimplicidadeCONTRASRapidezmais colisões (para qualquer tamanho de um HashMap)determinismo, que se propaga a outros objetos, tornando-os inutilizáveis parasimulações determinísticasComputação ETagcaçar bugs dependendo, p. com umHashSet ordem de iteração

Pessoalmente, eu prefiro o hashCode mais agradável, mas IMHO não pesa muito, talvez com exceção da velocidade.

ATUALIZAR

Fiquei curioso sobre a velocidade e escrevi umreferência com surpreendenteresultados. Por um preço de um único campo por classe, é possível um código hash determinístico que é quasequatro vezes mais rapido. Armazenar o código hash em cada campo seria ainda mais rápido, embora insignificante.

A explicação do motivo pelo qual o código hash padrão não é muito mais rápido é que ele não pode ser o endereço do objeto, pois os objetos são movidos pelo GC.

ATUALIZAÇÃO 2

Há algumas coisas estranhasindo com ohashCode desempenho em geral. Quando eu os entendo, ainda há a pergunta em aberto, por queSystem.identityHashCode (ler no cabeçalho do objeto) é muito mais lento que acessar um campo de objeto normal.