On Thu, 7 Jan 2021 19:50:44 GMT, Valerie Peng <[email protected]> wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments from @valeriep
>
> src/java.base/share/classes/java/security/Provider.java line 1072:
>
>> 1070: }
>> 1071: public int hashCode() {
>> 1072: return 31*31 + type.hashCode()*31 + algorithm.hashCode();
>
> Well, perhaps we just revert to Objects.hash(...) (better readability and
> potential future enhancement in case one is available)? Or, if we want to
> adopt the same calculation based on current Objects.hash(..) impl, the 31*31
> part doesn't not seem to be too useful and can be removed for this particular
> case.
Robustly optimizing the JIT so that `Objects.hash` can avoid creating the
`Object[]` might be further off than we'd like to think.
I think the one-liner proposed here is a good tradeoff between performance and
maintainability/readability in a _global_ sense: this one-liner avoids
non-trivial overhead and allocation that might otherwise still be a strong
enough motivator to cache calls to `MessageDigest.getInstance` at call-sites
such as in `UUID::nameUUIDFromBytes`.
Removing the 31*31 factor shouldn't hurt how well-distributed hashes get, just
shuffle things around. I'll remove it.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1933
