RFR: 8311170: Simplify and modernize equals and hashCode in security area [v4]
Pavel Rappo
prappo at openjdk.org
Wed Jul 5 20:43:56 UTC 2023
On Wed, 5 Jul 2023 18:04:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>>
>> - Merge branch 'master' into 8311170
>> - Be consistent with the rest of the change
>> - Fix reported bugs
>> - Add even more cases and tidy up
>> - More cases
>> - Initial commit
>
> src/java.base/share/classes/javax/security/cert/Certificate.java line 107:
>
>> 105: try {
>> 106: return Arrays.hashCode(this.getEncoded());
>> 107: } catch (CertificateException e) {
>
> Ditto, what value at `certData[0]` is now included in the hash?
Those are correct observations. Unspecified hashCode methods changed in this proposal might return different values than the ones they currently return in the mainline; hence my disclaimer in this PR description:
> This PR sacrifices compatibility for pragmatism: it changes some hashCode implementations to produce different values than before to allow more utilization of methods from Objects and Arrays. To my mind, those changes are **benign**. If you disagree, I'd be happy to discuss that and/or retract the concerning part of the change.
I'm waiting from someone from security-dev to tell me if that's okay to skip zeroth elements in both hashCode. It might've been an accidental skip in the first place. FWIW, their `equals` counterparts do not skip zeroth elements. On the other hand, javax.security.cert.Certificate is deprecated for removal, so I might as well exclude it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14738#discussion_r1253622642
More information about the security-dev
mailing list