<i18n dev> RFR: 8311188: Simplify and modernize equals and hashCode in java.text

[Pavel Rappo]

On Mon, 3 Jul 2023 13:22:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify `equals` and `hashCode` in the java.text area.
>> 
>> * Some changes to `equals` and `hashCode` are refactoring rather than modernization. Such changes can be as trivial as rearranging, adding, or commenting checks.
>> 
>> * java.text area contains more classes whose `equals` and `hashCode` could be simplified; for example: sun.text.CompactByteArray or java.text.DigitList. However, I found no evidence of `equals` and `hashCode` in those classes being used in source or tests. Since writing new tests in this case seems unreasonable, I **excluded** those classes from this PR.
>
> src/java.base/share/classes/java/text/AttributedString.java line 661:
> 
>> 659: 
>> 660:     // returns whether the two objects are either both null or equal
>> 661:     private static boolean valuesMatch(Object value1, Object value2) {
> 
> Can this be simply inlined, that its occurrences are replaced by Objects.equals?

It certainly can, but...

I've been working on a similar PR for the java.util package. That package has lots of performance-sensitive locations that could also use `Objects.equals`. In that package, I ran into comments referring to an issue with using Object.equals: [JDK-8015417](https://bugs.openjdk.org/browse/JDK-8015417). So, I might do some additional research before integrating this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1251354662