A library for implementing equals and hashCode

[Stuart Marks]

On 4/22/19 11:29 AM, Liam Miller-Cushon wrote:
> Please consider this proposal for a library to help implement equals and
> hashCode.
> 
> The doc includes a discussion of the motivation for adding such an API to
> the JDK, a map of the design space, and some thoughts on the subset of that
> space which might be most interesting:
> 
> http://cr.openjdk.java.net/~cushon/amber/equivalence.html

Hi Liam,

Thanks for the discussion here. I don't have many specific points to add at the 
moment, but as you probably know, this has been discussed before. I think it 
would be useful to add links to those previous discussions to help comparison 
and analysis.

There are a couple RFEs in JIRA that cover this and related topics:

     JDK-4771660 (coll) Comparator, Comparable, Identity, and Equivalence
     JDK-6270657 (coll) remove/contains and "Equators" other than .equals()

Note these are filed under the collections subcomponent since that's where most 
of the use cases seem to fall, e.g., for set.contains(obj) [unless the set is a 
SortedSet, blah blah blah].

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

On hashing, the base-31 polynomial is certainly "traditional" but it's not 
without faults. John Rose wrote up a bunch of notes in the form of a draft JEP;

     JDK-8201462 Better hash codes

I don't know if this is going anywhere as a JEP at the moment, but it certainly 
points out that we can do better by default than the base-31 formula.

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.

s'marks