Value type hash code (original) (raw)

Remi Forax forax at univ-mlv.fr
Wed Apr 11 18:32:29 UTC 2018

----- Mail original -----

De: "daniel smith" <daniel.smith at oracle.com> À: "Brian Goetz" <brian.goetz at oracle.com> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net> Envoyé: Mercredi 11 Avril 2018 18:40:25 Objet: Re: Value type hash code

On Apr 11, 2018, at 9:42 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

One of the operations we can name is ==. I think the substitution check is the most reasonable interpretation of ==, but I don't really see how we can avoid recurring on .equals() for the equals() implementation. Otherwise, this will violate basic user expectations, such as: value record StringBox(String s); I think values would be near-useless under such an interpretation of equals(). This is a reasonable language design, but I don't think the JVM should hard-wire that behavior. The compiler can generate the equals/hashCode methods it wants, and my thinking is that when the compiler fails to do so, the JVM's default (that is, the behavior of Object.equals and Object.hashCode if not overridden) should be conservative.

I think we can go a step further and do not provide any defaults.

The default implementation of equals and hashCode in java/lang/Object make only sense for reference, for value types, it depends on the value type, i.e, it's far easier for the compiler to provide an equals/hashCode than for the VM, hence my proposition that the VM should not provide any default and let the compiler of the different languages decide what defaults are.

—Dan

Rémi

More information about the valhalla-dev mailing list