Value type hash code

Dan Smith daniel.smith at
Wed Apr 11 16:40:25 UTC 2018

> On Apr 11, 2018, at 9:42 AM, Brian Goetz <brian.goetz at> 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.


More information about the valhalla-dev mailing list