A library for implementing equals and hashCode

Liam Miller-Cushon cushon at google.com
Wed Apr 24 22:52:10 UTC 2019

Hi Stuart,

Thanks for the background! I added your links to the doc.

On Tue, Apr 23, 2019 at 6:06 PM Stuart Marks <stuart.marks at oracle.com>

> I think the Odersky article about Java equals() methods that was referred
> to
> elsewhere is this one:
>      https://www.artima.com/lejava/articles/equality.html

I think the crux of this is the effect on substitutability. I'm not sure
we're going to be
able to provide a single opinionated solution to writing equals methods on
Winning here might be making it possible (and reasonably ergonomic) to
express the
common approaches to this problem.

> Finally, I agree that the hash function should be left unspecified, but if
> it
> has a well-known and predictable implementation, it will shortly become
> the "de
> facto" specification and will be very difficult to change in the future.
> I'm
> therefore in favor of more aggressive approaches to create a defensible
> space
> for future changes. This might include randomization, perhaps on by
> default,
> perhaps opt-out, or possibly something else.

As mentioned in the doc we've had good results randomizing the iteration
order of
hash-based containers at Google, but we're only doing it in tests.

Other languages have had success with being more aggressive, for example go
always randomizes the iteration order of maps.

More information about the amber-spec-observers mailing list