RFR: 8311170: Simplify and modernize equals and hashCode in security area [v12]

[Sean Mullan]

On Fri, 4 Aug 2023 15:01:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/PolicyInformation.java line 140:
>> 
>>> 138:     @Override
>>> 139:     public int hashCode() {
>>> 140:         return Objects.hash(policyIdentifier, policyQualifiers);
>> 
>> What is the criteria for changing the hashCode() impl? It seems that you change some and not others. With the many hashCode() impls (e.g. Objects.hash(), Arrays.hashCode()), I wonder why this and not that.
>
> Whether I suggest changing hashCode or not depends on multiple criteria, of which these two are the most important:
> 
>   * Is the value specified or relied upon?
>   * Does it need to be performant?
> 
> If the answer to both of these is "NO", I might refactor hashCode. One unintended side effect, is that sometimes such a refactoring improves hashCode quality (think: perfect hashing) almost for free.
> 
> If you have concerns on particular refactorings, I'd be happy to discuss them.

I would add to that list that I think it is really important any change to the `hashCode` impl doesn't break the equals/hashCode contract, so it's important to look at the `equals` implementation in conjunction with any changes to `hashCode`, mostly to ensure 2 equal objects continue to have the same hash code. It is also important to question any oddity about the `hashCode` impl, like I did for DESKey and try to understand why it may have been implemented that way, such as skipping the first byte.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1284801790