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

Valerie Peng valeriep at openjdk.org
Mon Aug 7 21:42:36 UTC 2023


On Fri, 4 Aug 2023 22:00:41 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBError.java line 523:
>> 
>>> 521:         if (crealm != null) result = 37 * result + crealm.hashCode();
>>> 522:         if (cname != null) result = 37 * result + cname.hashCode();
>>> 523:         if (sname != null) result = 37 * result + sname.hashCode();
>> 
>> Why changing the ordering? I was wondering if you'd change this to Objects.hash(...) with all the fields as arguments.
>
>> Why changing the ordering?
> 
> The order was changed to be parallel with that of `equals`.
> 
>> I was wondering if you'd change this to Objects.hash(...) with all the fields as arguments.
> 
> Sure, we could use a convenience method, but because `eData` is an array, it should be `Arrays.deepHashCode(..., eData, ...)` or this construct:
> 
>     Objects.hash(..., Arrays.hashCode(eData), ...)
> 
> Bottom line: as long as we include all eData elements in the computation, we should be fine. If we fail to do that, we'll violate the equals-hashCode contract.

Ok.

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

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



More information about the security-dev mailing list