A library for implementing equals and hashCode
stuart.marks at oracle.com
Thu Apr 25 00:39:23 UTC 2019
>> However, I can see that
>> some applications might want greater control over the actual hash
>> function, so
>> that capability probably will need to be provided through the API somehow.
> I would disagree with this strongly. Use cases that require a *quality* hash
> code really need to use a proper hashing library like (bias alert) Guava's.
> It can produce quality results because its API is designed for that.
By "quality" hash code, do you mean a cryptographic hash? If so, then yes,
that's really quite separate, and I'm not proposing supporting such a thing here.
Here's what I meant by "greater control". Liam's proposal talks about providing
a hash reduce function implementation that is unspecified, allowing for the
possibility of it changing in the future. Some applications will be fine with this.
Other applications might want to use this API for convenience, or cleaner code,
or something, but which might want to use their own hash reduce function in
order to preserve compatibility. They might want to replicate the hash function
used in the past, or they might want to ensure that the hash function doesn't
change out from under them in a future release. These applications might require
"greater control" in the API of the hash reduce function.
On the other hand, maybe we don't need to support this use case, in which case
the need for greater control goes away.
I'm not taking a position on this; I'm just mapping out the design space.
More information about the amber-spec-observers