----- Original Message -----
> From: "dfranken jdk" <dfranken....@gmail.com>
> To: "core-libs-dev" <core-libs-dev@openjdk.java.net>
> Sent: Thursday, March 17, 2022 1:49:08 PM
> Subject: Making enum hashcodes consistent across JVM's
> Dear all,
>
> Currently enums do not have a well-defined hashCode() implementation so
> they defer to Object.hashCode() which just uses an internal mechanism
> to determine the hashcode, likely based on the object's place in the
> heap.
No, and no.
Enum.hashCode() is well defined, it is equivalent to super.hashCode() and it
can not be overridden by a specific enum (see the javadoc).
>
> This may confuse a lot of developers as other classes such as String do
> have a well-defined hashcode which is consistent across multiple JVM's.
One of the reasons why String.hashCode() is defined is because the compiler
(javac) compiles a switch on String using String.hashCode() so the hashCode at
compile time and at runtime has to be the same.
Having a well defined hashCode was a mistake, first it means that we can not
change the implementation later (the current hashCode of String has too many
collisions) and it also make DDOS attacks easier because you can pre-compute a
list of strings with the same hashCode.
>
> Could it be a good idea to make enums' hashCode() method more reliably
> and predictable? For instance by using the hashcode of the name of its
> value?
Enum already have a kind of perfect hash, ordinal() which is reliable and
predictable but it's not a great value as hashCode.
>
> For example:
>
> class MyEnum { A, B }
> -> A.hashCode() == A.name().hashCode()
This is not a good hashCode,
enum Foo { Aa, BB }
Foo.Aa.hashCode() == Foo.BB.hashCode()
>
> Kind regards,
>
> Dave Franken
regards,
Rémi
