RFR: 8365077: java.awt.font.NumericShaper violates equals/hashCode contract

Alexander Zuev kizune at openjdk.org
Fri Oct 17 06:49:04 UTC 2025


On Mon, 13 Oct 2025 17:53:44 GMT, Phil Race <prr at openjdk.org> wrote:

> The problem here is that NumericShaper can be constructed either using Range enum members
> or a bitmask.
> And the bitmask can represent the same (equal) NumericShaper as one constructed using
> the equivalent Range enum members and "boolean equals(Object)" handles this and there
> is support in the Range enum for a Set<Range> for this which is used by equals.
> 
> However the hashCode() does not have similar support and is quite different.
> The fix adds support for this.
> If the instance has a Set<Range> then use this new support, which will return
> the same hash as if it was constructed using a mask. In cases where this is not
> possible because Range instances  have no mask equivalent there is no issue
> because these cannot be equal either.
> 
> 
> EASTERN_ARABIC over-rides ARABIC and there was an inconsistency in that
> when constructed with Ranges this ARABIC is removed but this isn't the case
> for when constructed with masks. 
> I had to fix that so that the hashes would be the same.
> 
> I also made one variable final that should have been final all along.
>  
> A test is provided.

Looks reasonable and test works as expected.

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27774#pullrequestreview-3348538055


More information about the client-libs-dev mailing list