A library for implementing equals and hashCode

[Liam Miller-Cushon]

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>
wrote:

> 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
subclasses.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190424/19e6fb28/attachment.html>