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
