From dholmes at openjdk.org  Mon Jul  3 00:37:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Jul 2023 00:37:05 GMT
Subject: <i18n dev> RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <egWyx-TC0_ifwBRZCgtOUHUelGvWv_ipqnExJL5ALK8=.b42be8b6-be09-4806-bb48-2fe6c29b2725@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

I don't think saving one volatile read is a reasonable trade-off for the loss of readability of this code change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1617048695

From stsypanov at openjdk.org  Mon Jul  3 08:36:04 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 3 Jul 2023 08:36:04 GMT
Subject: <i18n dev> Withdrawn: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <rMqOJxL7zS_BAT-CHDTsjuZnihcHx7ibbd2abQgTeVI=.f97ebf9d-f732-41b8-a89c-bf4a79363e7c@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/14692

From prappo at openjdk.org  Mon Jul  3 11:20:10 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 3 Jul 2023 11:20:10 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and hashCode
 in java.text
Message-ID: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>

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.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14752/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311188
  Stats: 121 lines in 15 files changed: 31 ins; 52 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/14752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14752/head:pull/14752

PR: https://git.openjdk.org/jdk/pull/14752

From lancea at openjdk.org  Mon Jul  3 12:07:54 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 3 Jul 2023 12:07:54 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <_hJmUpFIm_Cer-PPkqMT1L76HdOc2xpBw-49ysn5y-U=.025de91b-c972-4177-8e23-feaf6099caaf@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo 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.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1511056787

From naoto at openjdk.org  Mon Jul  3 17:08:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Jul 2023 17:08:59 GMT
Subject: <i18n dev> RFR: 8311183: Remove unused mapping test files
Message-ID: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>

There are unused charset mapping test files under `test/jdk/sun/nio/cs/mapping` directory, where one of them (`JIS0212.b2c.private`) has a questionable copyright header from the Unicode Consortium. They should be removed.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/14757/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311183
  Stats: 40027 lines in 6 files changed: 0 ins; 40027 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14757/head:pull/14757

PR: https://git.openjdk.org/jdk/pull/14757

From naoto at openjdk.org  Mon Jul  3 18:12:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Jul 2023 18:12:54 GMT
Subject: <i18n dev> RFR: 8310818: Refactor more Locale tests to use JUnit
In-Reply-To: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
Message-ID: <R4UAROrEuHNmhYEp7w_S72ktN29v_K9P_SG106IliUI=.b212696c-eeba-44ed-a1a7-487d45c2a4a1@github.com>

On Fri, 30 Jun 2023 07:52:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors additional tests in Locale to use JUnit.
> 
> If a test was named bugNNNNNNN.java, it was renamed to something more descriptive.
> 
> Below is a list of all the changes
> 
> - Refactor and Rename Bug4175998Test.java as ISO639.java
> - Refactor and Rename Bug8001562.java as JDK7LocaleServiceDiffs.java
> - Refactor and Rename Bug8008577.java as ExpectedAdapterTypes.java
> - Refactor Bug8025703.java
> - Refactor and Rename Bug8026766.java as LRToString.java
> - Refactor and Rename Bug8071929.java as ISO3166.java
> - Refactor and Rename Bug8032842.java to PreserveTagCase.java

test/jdk/java/util/Locale/Bug8025703.java line 48:

> 46:      * language priority list by matching the correct tag(s). This test
> 47:      * was originally created to verify an older update to the LSR data file,
> 48:      * and the test may be deprecated by LanguageSubtagRegistryTest.java

If that's the case, can we update `LanguageSubtagRegistryTest.java` to cover these older updates and remove this test?

test/jdk/java/util/Locale/ISO639.java line 299:

> 297: 
> 298: // CODES generated from https://www.loc.gov/standards/iso639-2/ISO-639-2_utf-8.txt
> 299: // on March 9th, 2023.

Should be `expectedISO639Codes` instead of `CODES`, and this comment would be better placed on top of `expectedISO639Codes` method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14721#discussion_r1251159222
PR Review Comment: https://git.openjdk.org/jdk/pull/14721#discussion_r1251155431

From naoto at openjdk.org  Mon Jul  3 20:48:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Jul 2023 20:48:53 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <Lq67tFovUjWJoWxs655dwkkjg2UAuNQLWWZNdK9zPys=.82bcb1bf-20b3-4b92-a990-16c9d3210a1e@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo 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.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1511762190

From liach at openjdk.org  Mon Jul  3 23:52:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Jul 2023 23:52:52 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo 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?

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

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

From prappo at openjdk.org  Tue Jul  4 00:24:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 00:24:53 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
Message-ID: <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>

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

From liach at openjdk.org  Tue Jul  4 00:42:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Jul 2023 00:42:58 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
Message-ID: <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>

On Tue, 4 Jul 2023 00:22:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 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.

Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.

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

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

From prappo at openjdk.org  Tue Jul  4 01:04:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 4 Jul 2023 01:04:07 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
Message-ID: <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>

On Tue, 4 Jul 2023 00:40:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.

If that's true, then perhaps those (and some other) locations got that idea wrong:
* https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
* https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585

Maybe @rose00 could clarify that? 

FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.

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

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

From jrose at openjdk.org  Tue Jul  4 22:06:53 2023
From: jrose at openjdk.org (John R Rose)
Date: Tue, 4 Jul 2023 22:06:53 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
Message-ID: <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>

On Tue, 4 Jul 2023 01:01:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
>
>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
> 
> If that's true, then perhaps those (and some other) locations got that idea wrong:
> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585
> 
> Maybe @rose00 could clarify that? 
> 
> FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.

I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn?t, and how (maybe) to fix that.

https://cr.openjdk.org/~jrose/jvm/equals-profile.html
https://cr.openjdk.org/~jrose/jvm/equals-profile.md

This is also attached to the JBS bug.

The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases.  Sadly, JDK refactoring by itself will not get all the way to where we want to go.  The JVM?s profiling logic needs tweaking.

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

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

From rriggs at openjdk.org  Wed Jul  5 15:57:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 15:57:59 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
Message-ID: <yFxgKKwY3_83gXHrJtjTdGoqE-0fVv3sPpu_XdDBjgE=.1cc447b5-776f-478a-9aa6-e822505131f6@github.com>

On Tue, 4 Jul 2023 22:03:58 GMT, John R Rose <jrose at openjdk.org> wrote:

>>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
>> 
>> If that's true, then perhaps those (and some other) locations got that idea wrong:
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585
>> 
>> Maybe @rose00 could clarify that? 
>> 
>> FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.
>
> I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn?t, and how (maybe) to fix that.
> 
> https://cr.openjdk.org/~jrose/jvm/equals-profile.html
> https://cr.openjdk.org/~jrose/jvm/equals-profile.md
> 
> This is also attached to the JBS bug.
> 
> The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases.  Sadly, JDK refactoring by itself will not get all the way to where we want to go.  The JVM?s profiling logic needs tweaking.

I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.

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

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

From rriggs at openjdk.org  Wed Jul  5 15:57:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 15:57:57 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo 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.

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364:

> 2362:             return true;
> 2363:         }
> 2364: 

Moving this before the `super.equals` call  performance-wise would favor the equals case. (statistics not available guess)

The code style in these files favors `if (this == obj)`... over the swapped order of arguments.

src/java.base/share/classes/java/text/DecimalFormat.java line 2926:

> 2924:         if (obj == this) { // disambiguate super equality from ref equality
> 2925:             return true;
> 2926:         }

Ditto comment in CompactNumberFormat.

src/java.base/share/classes/java/text/DecimalFormat.java line 2930:

> 2928:         DecimalFormat other = (DecimalFormat) obj;
> 2929:         return ((posPrefixPattern == other.posPrefixPattern &&
> 2930:                  positivePrefix.equals(other.positivePrefix))

This might also be:

return (obj instanceof DecimalFormat other) && 
                 posPrefixPattern == other.posPrefixPattern &&
                 positivePrefix.equals(other.positivePrefix));

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

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1514810525
PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253309018
PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253310120
PR Review Comment: https://git.openjdk.org/jdk/pull/14752#discussion_r1253317064

From prappo at openjdk.org  Wed Jul  5 16:35:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 16:35:11 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v2]
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <4pOxaS_C1TBzmH44xKGHlMnKGriFIZT7RNfvU62hY1w=.02d9ea08-365b-4744-8a36-1bce19a393fc@github.com>

> 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.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Adhere to surrounding code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14752/files
  - new: https://git.openjdk.org/jdk/pull/14752/files/e5497367..b338480e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14752/head:pull/14752

PR: https://git.openjdk.org/jdk/pull/14752

From prappo at openjdk.org  Wed Jul  5 16:35:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 16:35:13 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v2]
In-Reply-To: <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
Message-ID: <_5Dma3GpgEds2ywyD4xBZ32Mqmu6NWl4-uv_jQWRBnY=.da3bfa73-2b98-4639-88f0-f6b48dffb2a9@github.com>

On Wed, 5 Jul 2023 15:47:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adhere to surrounding code style
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 2926:
> 
>> 2924:         if (obj == this) { // disambiguate super equality from ref equality
>> 2925:             return true;
>> 2926:         }
> 
> Ditto comment in CompactNumberFormat.

Fixed this and the other one in b338480e540.

> src/java.base/share/classes/java/text/DecimalFormat.java line 2930:
> 
>> 2928:         DecimalFormat other = (DecimalFormat) obj;
>> 2929:         return ((posPrefixPattern == other.posPrefixPattern &&
>> 2930:                  positivePrefix.equals(other.positivePrefix))
> 
> This might also be:
> 
> return (obj instanceof DecimalFormat other) && 
>                  posPrefixPattern == other.posPrefixPattern &&
>                  positivePrefix.equals(other.positivePrefix));

Do you mean we could use `obj instanceof DecimalFormat other` in front of that 30-line `&&` expression, or that we could collapse the list to exactly what you wrote?

Separately, `super.equals` already performs the class check; so enhanced `instanceof` could be used only as a syntactic sugar, but even then it won't decrease the line count: we trade one line for another very similar line.

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

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

From prappo at openjdk.org  Wed Jul  5 16:42:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 16:42:55 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v2]
In-Reply-To: <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
Message-ID: <jWff4xux0qab4756UxzvazeDXGY_x83TYbnXlEZKVHM=.54a58dc3-c99a-4878-9c51-c2db981b84b0@github.com>

On Wed, 5 Jul 2023 15:46:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adhere to surrounding code style
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364:
> 
>> 2362:             return true;
>> 2363:         }
>> 2364: 
> 
> Moving this before the `super.equals` call  performance-wise would favor the equals case. (statistics not available guess)
> 
> The code style in these files favors `if (this == obj)`... over the swapped order of arguments.

You are right, I have no stats. Performance-wise, it's already better than what was there before. Before, there was no short-circuit check. But I can go either way; I don't have a strong opinion.

Reusing superclass' equals is not often seen these days (and that code is old), so some amount of overlap is expected. Regardless of whether we rearrange that check or not, if the passed object is not `this`, we end up checking `this == obj` twice: once in super.equals, the other time in here.

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

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

From prappo at openjdk.org  Wed Jul  5 16:50:19 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 16:50:19 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v3]
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <6im2y4KWWzErV1MQU-rs2ufaliio0mE5Rekv9_T9CWc=.f43c6952-2d6d-4be0-ac95-2683b1d61f35@github.com>

> 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.

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 three additional commits since the last revision:

 - Merge branch 'master' into 8311188
 - Adhere to surrounding code style
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14752/files
  - new: https://git.openjdk.org/jdk/pull/14752/files/b338480e..641fb1e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=01-02

  Stats: 1750 lines in 166 files changed: 747 ins; 349 del; 654 mod
  Patch: https://git.openjdk.org/jdk/pull/14752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14752/head:pull/14752

PR: https://git.openjdk.org/jdk/pull/14752

From lancea at openjdk.org  Wed Jul  5 16:53:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 5 Jul 2023 16:53:53 GMT
Subject: <i18n dev> RFR: 8311183: Remove unused mapping test files
In-Reply-To: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
References: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
Message-ID: <R8ahjexrLcvRbR6n70YCDpumO9JLciTtQVMerSBeF7A=.74722922-81d0-4540-9368-f8baec231d4b@github.com>

On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There are unused charset mapping test files under `test/jdk/sun/nio/cs/mapping` directory, where one of them (`JIS0212.b2c.private`) has a questionable copyright header from the Unicode Consortium. They should be removed.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14757#pullrequestreview-1514950023

From bpb at openjdk.org  Wed Jul  5 17:08:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 5 Jul 2023 17:08:56 GMT
Subject: <i18n dev> RFR: 8311183: Remove unused mapping test files
In-Reply-To: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
References: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
Message-ID: <QL1mu3tMUJKOVgFNb03imzSoky1Gk6bnGaQSQDBpHcE=.95e04215-5022-43bc-97a3-ff717657e5fa@github.com>

On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There are unused charset mapping test files under `test/jdk/sun/nio/cs/mapping` directory, where one of them (`JIS0212.b2c.private`) has a questionable copyright header from the Unicode Consortium. They should be removed.

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14757#pullrequestreview-1514980588

From rriggs at openjdk.org  Wed Jul  5 17:43:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 17:43:03 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v3]
In-Reply-To: <_5Dma3GpgEds2ywyD4xBZ32Mqmu6NWl4-uv_jQWRBnY=.da3bfa73-2b98-4639-88f0-f6b48dffb2a9@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
 <_5Dma3GpgEds2ywyD4xBZ32Mqmu6NWl4-uv_jQWRBnY=.da3bfa73-2b98-4639-88f0-f6b48dffb2a9@github.com>
Message-ID: <cFabV-5KRjpZOfjT01AWzE6W3GoJtoGGQjeK3u0tVMw=.b1ad96d9-38b0-4fb6-843d-0215e9e359da@github.com>

On Wed, 5 Jul 2023 16:27:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormat.java line 2930:
>> 
>>> 2928:         DecimalFormat other = (DecimalFormat) obj;
>>> 2929:         return ((posPrefixPattern == other.posPrefixPattern &&
>>> 2930:                  positivePrefix.equals(other.positivePrefix))
>> 
>> This might also be:
>> 
>> return (obj instanceof DecimalFormat other) && 
>>                  posPrefixPattern == other.posPrefixPattern &&
>>                  positivePrefix.equals(other.positivePrefix));
>
> Do you mean we could use `obj instanceof DecimalFormat other` in front of that 30-line `&&` expression, or that we could collapse the list to exactly what you wrote?
> 
> Separately, `super.equals` already performs the class check; so enhanced `instanceof` could be used only as a syntactic sugar, but even then it won't decrease the line count: we trade one line for another very similar line.

Just what I wrote; I agree its a toss up from lines of code and performance.
I spotted that style in other files and its just a question of style; your choice.

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

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

From rriggs at openjdk.org  Wed Jul  5 17:48:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Jul 2023 17:48:01 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v3]
In-Reply-To: <jWff4xux0qab4756UxzvazeDXGY_x83TYbnXlEZKVHM=.54a58dc3-c99a-4878-9c51-c2db981b84b0@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
 <jWff4xux0qab4756UxzvazeDXGY_x83TYbnXlEZKVHM=.54a58dc3-c99a-4878-9c51-c2db981b84b0@github.com>
Message-ID: <IMTlpOXrBFPrUB2GTutRk-DnT-fqbHYNIww7ZY5lEaU=.7201c806-910b-49ac-acdb-2610eeb7e233@github.com>

On Wed, 5 Jul 2023 16:39:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364:
>> 
>>> 2362:             return true;
>>> 2363:         }
>>> 2364: 
>> 
>> Moving this before the `super.equals` call  performance-wise would favor the equals case. (statistics not available guess)
>> 
>> The code style in these files favors `if (this == obj)`... over the swapped order of arguments.
>
> You are right, I have no stats. Performance-wise, it's already better than what was there before. Before, there was no short-circuit check. But I can go either way; I don't have a strong opinion.
> 
> Reusing superclass' equals is not often seen these days (and that code is old), so some amount of overlap is expected. Regardless of whether we rearrange that check or not, if the passed object is not `this`, we end up checking `this == obj` twice: once in super.equals, the other time in here.

True, there's no simple way to avoid the double check in either the equal or not equal case.
And I don't know enough about the Hotspot compiler to know whether it would spot the duplication and optimize it.
In many `equals` methods, the test for self equality is frequently the first line.
Is fine as is.

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

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

From prappo at openjdk.org  Wed Jul  5 20:09:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 5 Jul 2023 20:09:55 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v3]
In-Reply-To: <cFabV-5KRjpZOfjT01AWzE6W3GoJtoGGQjeK3u0tVMw=.b1ad96d9-38b0-4fb6-843d-0215e9e359da@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
 <_5Dma3GpgEds2ywyD4xBZ32Mqmu6NWl4-uv_jQWRBnY=.da3bfa73-2b98-4639-88f0-f6b48dffb2a9@github.com>
 <cFabV-5KRjpZOfjT01AWzE6W3GoJtoGGQjeK3u0tVMw=.b1ad96d9-38b0-4fb6-843d-0215e9e359da@github.com>
Message-ID: <1fCuDas6gnda96PDU_iXDA6RcKm7jIs8LMYo5PffEwc=.7646081f-e335-4c46-9681-0eaf78ddad9e@github.com>

On Wed, 5 Jul 2023 17:39:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Do you mean we could use `obj instanceof DecimalFormat other` in front of that 30-line `&&` expression, or that we could collapse the list to exactly what you wrote?
>> 
>> Separately, `super.equals` already performs the class check; so enhanced `instanceof` could be used only as a syntactic sugar, but even then it won't decrease the line count: we trade one line for another very similar line.
>
> Just what I wrote; I agree its a toss up from lines of code and performance.
> I spotted that style in other files and its just a question of style; your choice.

I see. We are likely on the same page. My guess is that you saw incomplete source in "Files changed" on GitHub. In reality, that return statement spans 30 lines. I was initially confused by that trailing semicolon in your suggestion; I thought you propose to remove everything but those three lines, hence my question.

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

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

From naoto at openjdk.org  Wed Jul  5 23:31:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Jul 2023 23:31:04 GMT
Subject: <i18n dev> Integrated: 8311183: Remove unused mapping test files
In-Reply-To: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
References: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
Message-ID: <7t1XdHgfOIvk0W4hzJ-0ppHjR2W2DKUwKSK-3P7E3Yw=.32776839-6368-4556-9ee0-60a14d31e458@github.com>

On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> There are unused charset mapping test files under `test/jdk/sun/nio/cs/mapping` directory, where one of them (`JIS0212.b2c.private`) has a questionable copyright header from the Unicode Consortium. They should be removed.

This pull request has now been integrated.

Changeset: d072c40f
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d072c40ff175c653802796673baef47e24038891
Stats:     40027 lines in 6 files changed: 0 ins; 40027 del; 0 mod

8311183: Remove unused mapping test files

Reviewed-by: lancea, bpb

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

PR: https://git.openjdk.org/jdk/pull/14757

From naoto at openjdk.org  Thu Jul  6 00:38:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jul 2023 00:38:13 GMT
Subject: <i18n dev> [jdk21] RFR: 8311183: Remove unused mapping test files
Message-ID: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>

Hi all,

This pull request contains a backport of commit [d072c40f](https://github.com/openjdk/jdk/commit/d072c40ff175c653802796673baef47e24038891) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Naoto Sato on 5 Jul 2023 and was reviewed by Lance Andersen and Brian Burkhalter.

Thanks!

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

Commit messages:
 - Backport d072c40ff175c653802796673baef47e24038891

Changes: https://git.openjdk.org/jdk21/pull/98/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=98&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311183
  Stats: 40027 lines in 6 files changed: 0 ins; 40027 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/98.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/98/head:pull/98

PR: https://git.openjdk.org/jdk21/pull/98

From prappo at openjdk.org  Thu Jul  6 11:53:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 11:53:15 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v4]
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <4X2aZtSwlLRrWk0-bWXGypVemadA7ci1QBY29IyKNYs=.d7b03659-133d-4808-9ca5-e449afa11cc5@github.com>

> 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.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Re-arrange checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14752/files
  - new: https://git.openjdk.org/jdk/pull/14752/files/641fb1e5..f1ce3a10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=02-03

  Stats: 11 lines in 2 files changed: 3 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14752/head:pull/14752

PR: https://git.openjdk.org/jdk/pull/14752

From prappo at openjdk.org  Thu Jul  6 11:53:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 11:53:16 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v4]
In-Reply-To: <IMTlpOXrBFPrUB2GTutRk-DnT-fqbHYNIww7ZY5lEaU=.7201c806-910b-49ac-acdb-2610eeb7e233@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <91xHKdfKSLT4ZPVIAMHVGylThSOAaBTfIKMqXu7NaV8=.09068ea3-f6d8-4742-a52a-0a03fb15d1a1@github.com>
 <jWff4xux0qab4756UxzvazeDXGY_x83TYbnXlEZKVHM=.54a58dc3-c99a-4878-9c51-c2db981b84b0@github.com>
 <IMTlpOXrBFPrUB2GTutRk-DnT-fqbHYNIww7ZY5lEaU=.7201c806-910b-49ac-acdb-2610eeb7e233@github.com>
Message-ID: <s1mrmNlFEx8Hq-JM3pe4TEweILL_Wk6hRMIxXMnbRuY=.2da534e8-8d84-490a-a988-ce04d928f82d@github.com>

On Wed, 5 Jul 2023 17:44:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> You are right, I have no stats. Performance-wise, it's already better than what was there before. Before, there was no short-circuit check. But I can go either way; I don't have a strong opinion.
>> 
>> Reusing superclass' equals is not often seen these days (and that code is old), so some amount of overlap is expected. Regardless of whether we rearrange that check or not, if the passed object is not `this`, we end up checking `this == obj` twice: once in super.equals, the other time in here.
>
> True, there's no simple way to avoid the double check in either the equal or not equal case.
> And I don't know enough about the Hotspot compiler to know whether it would spot the duplication and optimize it.
> In many `equals` methods, the test for self equality is frequently the first line.
> Is fine as is.

Re-arranged the checks in f1ce3a1. You are right, this way is more conventional. As a bonus, we can dispense with the comment.

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

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

From prappo at openjdk.org  Thu Jul  6 14:49:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 14:49:55 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v4]
In-Reply-To: <yFxgKKwY3_83gXHrJtjTdGoqE-0fVv3sPpu_XdDBjgE=.1cc447b5-776f-478a-9aa6-e822505131f6@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <yFxgKKwY3_83gXHrJtjTdGoqE-0fVv3sPpu_XdDBjgE=.1cc447b5-776f-478a-9aa6-e822505131f6@github.com>
Message-ID: <qvXutZf0OG3yUBcf342TfbtwRD6-sJDIKmpP7eywdPU=.05a02263-1314-48a8-b20e-4c44422b6792@github.com>

On Wed, 5 Jul 2023 15:33:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.

I'll do something about them soon, Roger. But first I need to understand JDK-8015417 better, as it also affects other similar PRs already in review or in the works.

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

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

From prappo at openjdk.org  Thu Jul  6 16:19:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Jul 2023 16:19:55 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v4]
In-Reply-To: <qvXutZf0OG3yUBcf342TfbtwRD6-sJDIKmpP7eywdPU=.05a02263-1314-48a8-b20e-4c44422b6792@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <yFxgKKwY3_83gXHrJtjTdGoqE-0fVv3sPpu_XdDBjgE=.1cc447b5-776f-478a-9aa6-e822505131f6@github.com>
 <qvXutZf0OG3yUBcf342TfbtwRD6-sJDIKmpP7eywdPU=.05a02263-1314-48a8-b20e-4c44422b6792@github.com>
Message-ID: <JSKOtvQJzLz_TaXTLOggWvMZsWOIYoYgvywHCehbDyI=.0c33e78e-f070-4761-8687-738e8a038306@github.com>

On Thu, 6 Jul 2023 14:46:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.
>
>> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and remove the `valuesMatch` method as unnecessary.
> 
> I'll do something about them soon, Roger. But first I need to understand JDK-8015417 better, as it also affects other similar PRs already in review or in the works.

> I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn?t, and how (maybe) to fix that.
> 
> https://cr.openjdk.org/~jrose/jvm/equals-profile.html https://cr.openjdk.org/~jrose/jvm/equals-profile.md
> 
> This is also attached to the JBS bug.
> 
> The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases. Sadly, JDK refactoring by itself will not get all the way to where we want to go. The JVM?s profiling logic needs tweaking.

This PR has turned into an impromptu discussion on JDK-8015417. I think it's reasonable to continue it here, rather than to fork a separate discussion, because of (i) the relevance, (ii) context, and (iii) the fact that I have already pointed someone to this thread elsewhere.

Below is my mental model which I built based on your excellent write-up, John; is this model correct?

1. Inside a static method of a utility class, such as `java.util.Objects`,  `java.util.Arrays`, and `jdk.internal.util.ArraysSupport`, that have one or more parameters of `java.lang.Object` or arrays thereof, "observation of a static type" fails because `java.lang.Object` is the most inexact type possible.

2. Generics that might be available in the context of a call site of the said method do not _currently_ contribute to "observation of a static type" inside the said method:

        T obj = ...
        return Objects.hashCode(obj);

   It would still be true inside the method, if it used someone else's or its own generic parameters, as for example, `java.util.Objects.compare` does:

        public static <T> int compare(T a, T b, Comparator<? super T> c) {
            return (a == b) ? 0 :  c.compare(a, b);
        }

   In the sense of being opposite to "specific", generics are as "generic" as `java.lang.Object` and are not reifiable even for optimization purposes.

3. The above two points conclude the "observation of a static type" part of the issue. Our only hope is now (dynamic) profiling followed by successful type speculation.

4. Hand-inlining the said method is necessary but not sufficient to win the optimization. One way to avoid the need for hand-inlining is to annotate that method with `@ForceInline`.

5. Profiling/speculation leads to desired devirtualization of the call to an instance method, if the reference through which the call is made refers to an instance of an exact type (i.e. a `final` class or a primitive[^*]). Note: the reference itself does not need to be of an exact type. For example, this will do:

        Object s = "myString";
        ...
        java.util.Objects.hashCode(s);

4. Inside a general-purpose method, such as `Objects.hashCode(Object)`, profiling is noisy, and thus is unlikely to pan out a successful speculation. Outside such a general-purpose method, at its call site, profiling could be less noisy.

[^*]:  It cannot be primitive in this case, because we are only concerned with methods that accept `java.lang.Object`.
----

Let's further test that model by checking its predictions.

1. Consider mainline `java.util.AbstractMap.SimpleEntry`:

        public boolean equals(Object o) {
            return o instanceof Map.Entry<?, ?> e
                    && eq(key, e.getKey())
                    && eq(value, e.getValue());
        }

        /**
         * Utility method for SimpleEntry and SimpleImmutableEntry.
         * Test for equality, checking for nulls.
         *
         * NB: Do not replace with Object.equals until JDK-8015417 is resolved.
         */
        private static boolean eq(Object o1, Object o2) {
            return o1 == null ? o2 == null : o1.equals(o2);
        }

   Since everything here is either of type `java.lang.Object` or a wildcard, no information is contributed to "observation of a static type". That `eq` method is likely is as bad as `Objects.equals`, assuming our runtime operates on many maps of different parameterizations leading to a noisy profile. Which means that in this case, we can reasonably refactor that `equals` as follows:

        public boolean equals(Object o) {
            return o instanceof Map.Entry<?, ?> e
                    && Objects.equals(key, e.getKey())
                    && Objects.equals(value, e.getValue());
        }

   Similar reasoning could be applied to that same class' `hashCode`, to refactor it from this:

        public int hashCode() {
            return (key   == null ? 0 :   key.hashCode()) ^
                   (value == null ? 0 : value.hashCode());
        }

   to this:

        public int hashCode() {
            return (Objects.hashCode(key)) ^
                   (Objects.hashCode(value));
        }

   Unlike the previous example, however, where we trade one inlining for another, here we might lose the first layer of inlining. But assuming that `Objects.hashCode` is relatively small and additionally might get annotated with `@ForceInline` as a result of this discussion later on, it will be inlined.

2. Consider an opposite example:

        public class ECFieldF2m implements ECField {
            ...
            private BigInteger rp;
            ...
            public int hashCode() {
                int value = m << 5;
                value += (rp==null? 0:rp.hashCode());
                // no need to involve ks here since ks and rp
                // should be equivalent.
                return value;
            }
        }

   Would it be reasonable to change `hashCode` like this?

        public int hashCode() {
            int value = m << 5;
            value += Objects.hashCode(rp);
            // no need to involve ks here since ks and rp
            // should be equivalent.
            return value;
        }

   Firstly, we lose inlining. Secondly, the fact that `rp` is `BigInteger` is no longer immediately available to the actual hash code computation. Assuming that `java.util.Objects.hashCode` will be inlined at runtime, and given enough invocations, it will be profiled and subjected to class hierarchy analysis (CHA), which in the absence of `BigInteger.hashCode` overrides will hopefully determine that the call could be further inlined.

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

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

From lancea at openjdk.org  Thu Jul  6 18:10:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Jul 2023 18:10:53 GMT
Subject: <i18n dev> [jdk21] RFR: 8311183: Remove unused mapping test
 files
In-Reply-To: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>
References: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>
Message-ID: <llzgIkXYsP8hms8a-auZ-rWRUsRkPkb4vU7E-D4VSj8=.f24ca796-ffc0-4a41-a03a-a045b535a200@github.com>

On Thu, 6 Jul 2023 00:30:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d072c40f](https://github.com/openjdk/jdk/commit/d072c40ff175c653802796673baef47e24038891) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 5 Jul 2023 and was reviewed by Lance Andersen and Brian Burkhalter.
> 
> Thanks!

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/98#pullrequestreview-1517069942

From jlu at openjdk.org  Thu Jul  6 19:32:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Jul 2023 19:32:09 GMT
Subject: <i18n dev> RFR: 8310818: Refactor more Locale tests to use
 JUnit [v2]
In-Reply-To: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
Message-ID: <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>

> Please review this PR which refactors additional tests in Locale to use JUnit.
> 
> If a test was named bugNNNNNNN.java, it was renamed to something more descriptive.
> 
> Below is a list of all the changes
> 
> - Refactor and Rename Bug4175998Test.java as ISO639.java
> - Refactor and Rename Bug8001562.java as JDK7LocaleServiceDiffs.java
> - Refactor and Rename Bug8008577.java as ExpectedAdapterTypes.java
> - Refactor Bug8025703.java
> - Refactor and Rename Bug8026766.java as LRToString.java
> - Refactor and Rename Bug8071929.java as ISO3166.java
> - Refactor and Rename Bug8032842.java to PreserveTagCase.java

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Review: Remove Bug8025703.java and add to LSRT.java
 - Review: Clarify comments in ISO639.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14721/files
  - new: https://git.openjdk.org/jdk/pull/14721/files/f065726e..c1c55898

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14721&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14721&range=00-01

  Stats: 104 lines in 3 files changed: 12 ins; 88 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14721.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14721/head:pull/14721

PR: https://git.openjdk.org/jdk/pull/14721

From jlu at openjdk.org  Thu Jul  6 19:32:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Jul 2023 19:32:11 GMT
Subject: <i18n dev> RFR: 8310818: Refactor more Locale tests to use
 JUnit [v2]
In-Reply-To: <R4UAROrEuHNmhYEp7w_S72ktN29v_K9P_SG106IliUI=.b212696c-eeba-44ed-a1a7-487d45c2a4a1@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
 <R4UAROrEuHNmhYEp7w_S72ktN29v_K9P_SG106IliUI=.b212696c-eeba-44ed-a1a7-487d45c2a4a1@github.com>
Message-ID: <3Pq8FFVrmA70ZFYlK-MA0q_AWYQesAnFH2EwTWsZ9q4=.0d0915fd-ecdf-41bc-9494-b8ef0882e121@github.com>

On Mon, 3 Jul 2023 17:55:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review: Remove Bug8025703.java and add to LSRT.java
>>  - Review: Clarify comments in ISO639.java
>
> test/jdk/java/util/Locale/Bug8025703.java line 48:
> 
>> 46:      * language priority list by matching the correct tag(s). This test
>> 47:      * was originally created to verify an older update to the LSR data file,
>> 48:      * and the test may be deprecated by LanguageSubtagRegistryTest.java
> 
> If that's the case, can we update `LanguageSubtagRegistryTest.java` to cover these older updates and remove this test?

Yes, merged the tags from `Bug8025703.java` into `LanguageSubtagRegistryTest.java` and removed `Bug8025703.java`.

> test/jdk/java/util/Locale/ISO639.java line 299:
> 
>> 297: 
>> 298: // CODES generated from https://www.loc.gov/standards/iso639-2/ISO-639-2_utf-8.txt
>> 299: // on March 9th, 2023.
> 
> Should be `expectedISO639Codes` instead of `CODES`, and this comment would be better placed on top of `expectedISO639Codes` method

Adjusted

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14721#discussion_r1254834468
PR Review Comment: https://git.openjdk.org/jdk/pull/14721#discussion_r1254834584

From lancea at openjdk.org  Thu Jul  6 20:03:55 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Jul 2023 20:03:55 GMT
Subject: <i18n dev> RFR: 8310818: Refactor more Locale tests to use
 JUnit [v2]
In-Reply-To: <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
 <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>
Message-ID: <wBZjzIlrLtQBQEoMZ_Cq1zcqojEBZ6_WfFAr9ysZDoM=.45a7b316-528c-419b-ab7c-0cac3374b7e4@github.com>

On Thu, 6 Jul 2023 19:32:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors additional tests in Locale to use JUnit.
>> 
>> If a test was named bugNNNNNNN.java, it was renamed to something more descriptive.
>> 
>> Below is a list of all the changes
>> 
>> - Refactor and Rename Bug4175998Test.java as ISO639.java
>> - Refactor and Rename Bug8001562.java as JDK7LocaleServiceDiffs.java
>> - Refactor and Rename Bug8008577.java as ExpectedAdapterTypes.java
>> - Refactor Bug8025703.java
>> - Refactor and Rename Bug8026766.java as LRToString.java
>> - Refactor and Rename Bug8071929.java as ISO3166.java
>> - Refactor and Rename Bug8032842.java to PreserveTagCase.java
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review: Remove Bug8025703.java and add to LSRT.java
>  - Review: Clarify comments in ISO639.java

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14721#pullrequestreview-1517223095

From naoto at openjdk.org  Thu Jul  6 21:09:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jul 2023 21:09:59 GMT
Subject: <i18n dev> RFR: 8311528: Remove IDE specific SuppressWarnings
Message-ID: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>

Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/14790/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14790&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311528
  Stats: 15 lines in 1 file changed: 1 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14790.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14790/head:pull/14790

PR: https://git.openjdk.org/jdk/pull/14790

From naoto at openjdk.org  Thu Jul  6 21:09:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Jul 2023 21:09:55 GMT
Subject: <i18n dev> RFR: 8310818: Refactor more Locale tests to use
 JUnit [v2]
In-Reply-To: <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
 <o1Hev0mCe5cDNWWs0b0LdglJbd6vswi6rp6Tmug5eHo=.15af9fe4-a6e0-4e3b-ad49-d551e92cd297@github.com>
Message-ID: <WnHb7MHCrkREZDvADW4w2M6bMveSXI0Gj0JICT7hH0g=.bc5a1eae-55cb-4302-a467-6e9eb07aa9b4@github.com>

On Thu, 6 Jul 2023 19:32:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors additional tests in Locale to use JUnit.
>> 
>> If a test was named bugNNNNNNN.java, it was renamed to something more descriptive.
>> 
>> Below is a list of all the changes
>> 
>> - Refactor and Rename Bug4175998Test.java as ISO639.java
>> - Refactor and Rename Bug8001562.java as JDK7LocaleServiceDiffs.java
>> - Refactor and Rename Bug8008577.java as ExpectedAdapterTypes.java
>> - Combine Bug8025703.java into LanguageSubtagRegistryTest.java
>> - Refactor and Rename Bug8026766.java as LRToString.java
>> - Refactor and Rename Bug8071929.java as ISO3166.java
>> - Refactor and Rename Bug8032842.java to PreserveTagCase.java
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review: Remove Bug8025703.java and add to LSRT.java
>  - Review: Clarify comments in ISO639.java

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14721#pullrequestreview-1517315299

From lancea at openjdk.org  Thu Jul  6 21:17:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 6 Jul 2023 21:17:53 GMT
Subject: <i18n dev> RFR: 8311528: Remove IDE specific SuppressWarnings
In-Reply-To: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
References: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
Message-ID: <NY1ITAC-kGMZoLvW2OH8oXB0Qm-GvtmynyqPLxxjlQQ=.09c25eb4-0a4d-4f4f-a3fe-a386e9b5c2f8@github.com>

On Thu, 6 Jul 2023 21:03:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14790#pullrequestreview-1517325657

From bpb at openjdk.org  Thu Jul  6 21:26:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 6 Jul 2023 21:26:52 GMT
Subject: <i18n dev> RFR: 8311528: Remove IDE specific SuppressWarnings
In-Reply-To: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
References: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
Message-ID: <qciAMtic29U1TmuW_TmCc6eCeYE9I466_T3RLDZrBUE=.7d0ad62d-a8ad-4b25-84ea-6a1842017f6c@github.com>

On Thu, 6 Jul 2023 21:03:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14790#pullrequestreview-1517336153

From jlu at openjdk.org  Thu Jul  6 21:55:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 6 Jul 2023 21:55:54 GMT
Subject: <i18n dev> RFR: 8311528: Remove IDE specific SuppressWarnings
In-Reply-To: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
References: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
Message-ID: <4JZQk3Ln3OcJ-RBWfRCUwapfgz_R3vLiFhZH8ZFfqCA=.db4b4d2d-7cfc-4763-a9c8-426a08ef5abc@github.com>

On Thu, 6 Jul 2023 21:03:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14790#pullrequestreview-1517371749

From duke at openjdk.org  Thu Jul  6 23:35:09 2023
From: duke at openjdk.org (duke)
Date: Thu, 6 Jul 2023 23:35:09 GMT
Subject: <i18n dev> Withdrawn: 8301991: Convert l10n properties resource
 bundles to UTF-8 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <uaRK1W4uoY8WriKgYieJVUIGwgh0EMcgfXRicbKTmg4=.e68ef291-6589-493a-b7e9-8086097fb392@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12726

From smarks at openjdk.org  Thu Jul  6 23:40:56 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 6 Jul 2023 23:40:56 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v4]
In-Reply-To: <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
Message-ID: <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>

On Tue, 4 Jul 2023 22:03:58 GMT, John R Rose <jrose at openjdk.org> wrote:

>>> Hmm, I think that issue refers to code that have explicit non-Object parameter types (like `X::equals(Object)boolean` in the issue's sample). This method already have both arguments as `Object`, so I don't think there's any type-specific inlining opportunities.
>> 
>> If that's true, then perhaps those (and some other) locations got that idea wrong:
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/Collections.java#L5712-L5719
>> * https://github.com/openjdk/jdk/blob/faf1b822d03b726413d77a2b247dfbbf4db7d57e/src/java.base/share/classes/java/util/AbstractMap.java#L577-L585
>> 
>> Maybe @rose00 could clarify that? 
>> 
>> FWIW, I also note that `HashMap` does not use similar private static methods; it uses `Objects.equals(Object, Object)` and `Objects.hashCode` overloads that take parameters.
>
> I wrote a little case study on `Objects::equals` that talks about how it should optimize, when it does, why it doesn?t, and how (maybe) to fix that.
> 
> https://cr.openjdk.org/~jrose/jvm/equals-profile.html
> https://cr.openjdk.org/~jrose/jvm/equals-profile.md
> 
> This is also attached to the JBS bug.
> 
> The work on [JDK-8026251](https://bugs.openjdk.org/browse/JDK-8026251) with the `TypeProfileLevel` switch bring us closer to correctly optimizing `Objects::equals` in more cases.  Sadly, JDK refactoring by itself will not get all the way to where we want to go.  The JVM?s profiling logic needs tweaking.

Thanks @rose00 for the writeup and @pavelrappo for asking pertinent followup questions.

For me the issue here is that there is a bunch of lore about avoiding `Objects::equals` and it's embodied in comments like this:

> NB: Do not replace with Object.equals until JDK-8015417 is resolved. 

These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a "dead hand" at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?

As a side note, I observe that the `eq` method in Collections.java and AbstractMap.java does this:

    return o1 == null ? o2 == null : o1.equals(o2);

whereas `Objects::equals` will test `o1 == o2` and skip the `equals()` call if the references are non-null and equals. This might confound the comparison a bit.

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

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

From prappo at openjdk.org  Fri Jul  7 00:42:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 7 Jul 2023 00:42:15 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v4]
In-Reply-To: <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>
Message-ID: <r4-dPyuclFOYil8WAkurSA0wlwSF7wlugZX8LDa2qrE=.f7cde5c3-5882-4511-8548-10dea66522c5@github.com>

On Thu, 6 Jul 2023 23:38:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> For me the issue here is that there is a bunch of lore about avoiding `Objects::equals` and it's embodied in comments like this:
> 
> > NB: Do not replace with Object.equals until JDK-8015417 is resolved.
> 
> These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a "dead hand" at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?

Agree on all of the above; this is "rumor control".

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

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

From jlu at openjdk.org  Fri Jul  7 01:36:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Jul 2023 01:36:10 GMT
Subject: <i18n dev> Integrated: 8310923: Refactor Currency tests to use JUnit
In-Reply-To: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
Message-ID: <luD1BoKNWPX-r4oxKJrBlQWfnKEfjIDaQAo2NJivlxE=.7badbe3b-632b-4056-a222-0c13e5ff4904@github.com>

On Tue, 27 Jun 2023 19:04:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors Currency tests to use JUnit.
> 
> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
> 
> - Tests are no longer dependent on each other (order of execution does not matter)
> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
> 
> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.

This pull request has now been integrated.

Changeset: e848d947
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e848d9471f5de86e5ac157b710cd7371f12f0024
Stats:     1089 lines in 9 files changed: 436 ins; 372 del; 281 mod

8310923: Refactor Currency tests to use JUnit

Reviewed-by: naoto, lancea

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

PR: https://git.openjdk.org/jdk/pull/14682

From naoto at openjdk.org  Fri Jul  7 15:50:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Jul 2023 15:50:57 GMT
Subject: <i18n dev> [jdk21] Integrated: 8311183: Remove unused mapping test
 files
In-Reply-To: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>
References: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>
Message-ID: <mXOUrhkSigZ3545P9mvqlNBf-rFPL3yQ3zhTWbi4F-A=.7b022895-381f-4f58-9924-665b84cb975d@github.com>

On Thu, 6 Jul 2023 00:30:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [d072c40f](https://github.com/openjdk/jdk/commit/d072c40ff175c653802796673baef47e24038891) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 5 Jul 2023 and was reviewed by Lance Andersen and Brian Burkhalter.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 773bb0a7
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/773bb0a7f110bd58359498334d7084eaca897e3a
Stats:     40027 lines in 6 files changed: 0 ins; 40027 del; 0 mod

8311183: Remove unused mapping test files

Reviewed-by: lancea
Backport-of: d072c40ff175c653802796673baef47e24038891

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

PR: https://git.openjdk.org/jdk21/pull/98

From jlu at openjdk.org  Fri Jul  7 19:15:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Jul 2023 19:15:14 GMT
Subject: <i18n dev> Integrated: 8310818: Refactor more Locale tests to use
 JUnit
In-Reply-To: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
References: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>
Message-ID: <SLTZgI1cmZIjPOjpTkZwKoaZdyV8XSeEId-ve5C687s=.b791094f-9b61-4454-8874-a8b912be779c@github.com>

On Fri, 30 Jun 2023 07:52:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors additional tests in Locale to use JUnit.
> 
> If a test was named bugNNNNNNN.java, it was renamed to something more descriptive.
> 
> Below is a list of all the changes
> 
> - Refactor and Rename Bug4175998Test.java as ISO639.java
> - Refactor and Rename Bug8001562.java as JDK7LocaleServiceDiffs.java
> - Refactor and Rename Bug8008577.java as ExpectedAdapterTypes.java
> - Combine Bug8025703.java into LanguageSubtagRegistryTest.java
> - Refactor and Rename Bug8026766.java as LRToString.java
> - Refactor and Rename Bug8071929.java as ISO3166.java
> - Refactor and Rename Bug8032842.java to PreserveTagCase.java

This pull request has now been integrated.

Changeset: 12e94309
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12e943091071b02b5756b57527a5f86a3d881cb8
Stats:     1377 lines in 13 files changed: 681 ins; 686 del; 10 mod

8310818: Refactor more Locale tests to use JUnit

Reviewed-by: lancea, naoto

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

PR: https://git.openjdk.org/jdk/pull/14721

From naoto at openjdk.org  Mon Jul 10 17:10:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Jul 2023 17:10:20 GMT
Subject: <i18n dev> Integrated: 8311528: Remove IDE specific SuppressWarnings
In-Reply-To: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
References: <jRthDb07OuAapZb1YDvwFvWbnOmVn5wN_Pb2f7MeXFA=.0d8e4170-7364-4ba5-8bc7-c5de6d102fc1@github.com>
Message-ID: <jo6IgqyipyEM2QDIbBRwOtxCEYjGW1_nECOSi-JgKvM=.08a5a920-2152-45a2-9e70-f1f993548df8@github.com>

On Thu, 6 Jul 2023 21:03:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the IDE specific `@SuppressWarnings` attached to `java.util.Calendar#equals()`. `equals()` implementation now checks the type of the other instance for this.

This pull request has now been integrated.

Changeset: 63f32fbe
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63f32fbe9771b8200f707ed5d1d0e6555ad90f8b
Stats:     15 lines in 1 file changed: 1 ins; 1 del; 13 mod

8311528: Remove IDE specific SuppressWarnings

Reviewed-by: lancea, bpb, jlu

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

PR: https://git.openjdk.org/jdk/pull/14790

From jlu at openjdk.org  Tue Jul 11 17:15:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Jul 2023 17:15:21 GMT
Subject: <i18n dev> Integrated: 6960866: [Fmt-Ch] ChoiceFormat claims
 impossible and unimplemented functionality
In-Reply-To: <c5Tn7PWZHbcxFWiTotcm9K-08xyu0ctxbuhvgFxIzXE=.af1dbece-46ad-4ce0-9437-d225e898a7a7@github.com>
References: <c5Tn7PWZHbcxFWiTotcm9K-08xyu0ctxbuhvgFxIzXE=.af1dbece-46ad-4ce0-9437-d225e898a7a7@github.com>
Message-ID: <pwgiH_72R9pIkv-9jKhYZ9H4fDc7_dN-g3GulA_eOfc=.b0267ba6-4a87-447c-9fbf-ab06667c4cb3@github.com>

On Thu, 29 Jun 2023 18:02:00 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which clarifies the parameter description of ChoiceFormat.setChoices().
> 
> `ChoiceFormat.setChoices(double[] limits, String[] formats)` claims that `formats` can either be "Format objects or Strings". It also claims that "When formatting with object Y, if the object is a NumberFormat, then ((NumberFormat) Y).format(X) is called. Otherwise Y.toString() is called".
> 
> This is not true as `formats` is an array of Strings. Thus, the second claim is impossible and unimplemented in the method itself.
> 
> The unimplemented specification should be removed from the parameter description.

This pull request has now been integrated.

Changeset: 6cb9ec32
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

6960866: [Fmt-Ch] ChoiceFormat claims impossible and unimplemented functionality

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/14715

From jrose at openjdk.org  Wed Jul 12 22:29:13 2023
From: jrose at openjdk.org (John R Rose)
Date: Wed, 12 Jul 2023 22:29:13 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v4]
In-Reply-To: <r4-dPyuclFOYil8WAkurSA0wlwSF7wlugZX8LDa2qrE=.f7cde5c3-5882-4511-8548-10dea66522c5@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>
 <r4-dPyuclFOYil8WAkurSA0wlwSF7wlugZX8LDa2qrE=.f7cde5c3-5882-4511-8548-10dea66522c5@github.com>
Message-ID: <9yQuD4s56Jx6Ks4ORj_mGSEIPOGg2YE9lua0uzhJJgs=.1f7b4918-88b9-4246-90b1-18c463cbbafb@github.com>

On Fri, 7 Jul 2023 00:39:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Thanks @rose00 for the writeup and @pavelrappo for asking pertinent followup questions.
>> 
>> For me the issue here is that there is a bunch of lore about avoiding `Objects::equals` and it's embodied in comments like this:
>> 
>>> NB: Do not replace with Object.equals until JDK-8015417 is resolved. 
>> 
>> These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a "dead hand" at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?
>> 
>> As a side note, I observe that the `eq` method in Collections.java and AbstractMap.java does this:
>> 
>>     return o1 == null ? o2 == null : o1.equals(o2);
>> 
>> whereas `Objects::equals` will test `o1 == o2` and skip the `equals()` call if the references are non-null and equals. This might confound the comparison a bit.
>
>> For me the issue here is that there is a bunch of lore about avoiding `Objects::equals` and it's embodied in comments like this:
>> 
>> > NB: Do not replace with Object.equals until JDK-8015417 is resolved.
>> 
>> These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a "dead hand" at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?
> 
> Agree on all of the above; this is "rumor control".

@pavelrappo

> Let's further test that model by checking its predictions.
> 
> ?Which means that in this case, we can reasonably refactor that `equals` as follows:
>    ```
>     public boolean equals(Object o) {
>         return o instanceof Map.Entry<?, ?> e
>                 && Objects.equals(key, e.getKey())
>                 && Objects.equals(value, e.getValue());
>     }
>    ```

Yes, I believe that is so.  Discounting (probably polluted) profile effects, it is no better and no worse to have your own helper `eq` or use the one in `Objects`.

>      
>    Similar reasoning could be applied to that same class' `hashCode`, to refactor it from this:
>    ```
>     public int hashCode() {
>         return (key   == null ? 0 :   key.hashCode()) ^
>                (value == null ? 0 : value.hashCode());
>     }
>    ```
>      
>    to this:
>    ```
>     public int hashCode() {
>         return (Objects.hashCode(key)) ^
>                (Objects.hashCode(value));
>     }
>    ```

Correct.

>    Unlike the previous example, however, where we trade one inlining for another, here we might lose the first layer of inlining. But assuming that `Objects.hashCode` is relatively small and additionally might get annotated with `@ForceInline` as a result of this discussion later on, it will be inlined.

Correct.

> 2. Consider an opposite example?
>      
>    Would it be reasonable to change `hashCode` like this?
>    ```
>     public int hashCode() {
>         int value = m << 5;
>         value += Objects.hashCode(rp);
>         // no need to involve ks here since ks and rp
>         // should be equivalent.
>         return value;
>     }
>    ```

Yes, it would be, because `rp` has a statically observable type, `BigInteger`.  And that observation will flow across the call to the helper method.

>    Firstly, we lose inlining.

I don?t get that; I?d rather say ?we assume the helper is inlined?.  Or are you talking about the hoped-for inlining of `recv.hashCode()`?  That works as long as a good-enough type of `recv` (`rp` or the formal to the helper) is observable.  In this case `BigInteger` is good.  If this were generic code and `rp` were `Object` then that would be not so good.

> Secondly, the fact that `rp` is `BigInteger` is no longer immediately available to the actual hash code computation. Assuming that `java.util.Objects.hashCode` will be inlined at runtime, and given enough invocations, it will be profiled and subjected to class hierarchy analysis (CHA), which in the absence of `BigInteger.hashCode` overrides will hopefully determine that the call could be further inlined.

This is mostly correct, except that we rely on the static type of `rp`, smuggled across the inlining barrier.  There is no need for profiling.  Indeed, it is rare for a profiled type to be used for CHA; that is mainly for statically observed types.

@stuart-marks

> These comments are almost exactly ten years old, and we can't seem to find any evidence showing that a slowdown occurred if `Objects::equals` were used. The comments are a ?dead hand? at this point. Is there a way to demonstrate whether there is or is not any difference when using `Objects::equals`?

(Ooh: The Mortmain Strikes Back!  I guess I scared somebody a decade ago.  Better get this sorted?)

I think we should mark these helpers `@ForceInline` and then take what winnings we can get from them.  That means either refactoring all candidate sites in the JDK to use the helpers, or refactoring all but those which are risky.

We need a risk assessment in either case, because even if we refactor everything we will have to be ready to fix performance outages (if significant) by either recoding or adding a touch more profiling into the JVM.  Just a touch; it can be focused on just these helpers, if they are made intrinsics.

(Definitions: The ?receiver? is the reference that will get the call to the `Object` method.  As it happens it is always the lead argument to the helper.  A ?usefully restrictive? type is one for which the eventual virtual method call will reach exactly one method.  Every `final` class is a usefully restrictive type, almost every interface is not usefully restrictive.)

Here are less risky use cases:

 - The receiver in the use case is statically typed to a usefully restrictive type
 - The dynamic type of the receiver is variable and can take on many values.

In the first case, inlining the helper will provide the JIT all the information it needs to devirtualize and inline the method it calls.

In the second case, we give up hope that the JIT will inline the method, whether or not we perform the refactorization.

The more risky use cases are all others:

 - The dynamic type of the receiver takes only one or two values, even if its type is not usefully restrictive.

This can happen with generic code, but mainly in microbenchmarks, which are artificially small programs.  At scale most generic code is multi-purpose, which means the values that flow through them have many dynamic types.  So I think refactoring inside widely-used generic code is safe, not risky.  Beware making policy here only with microbenchmarks.

In risky cases like this, the JVM?s profiling machinery captures useful information on the receiver at the use site, information that would be absent after refactoring the virtual call inside the helper method.  This can and should be fixed by targeted profiling on the arguments of exactly those helpers.

I think it is hard to find the risky cases.

(We can generalize this later as well, and HotSpot already has a flag for that.  I think setting `TypeProfileLevel` to 112 instead of its current default 111 would fix the helpers, and many other problems as well.  But it would have an unpredictable effect on startup and footprint.  Targeting it to just our special helpers is likely to have no adverse effects.)

The above discussion applies to both `equals` and `hashCode`.  For `equals` there is a secondary effect from type observations on the second argument, but it only matters if we are already winning and inlining the virtual method.

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

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

From jlu at openjdk.org  Thu Jul 13 18:36:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 18:36:29 GMT
Subject: <i18n dev> [jdk21] RFR: 6960866: [Fmt-Ch] ChoiceFormat claims
 impossible and unimplemented functionality
Message-ID: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>

Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d

Thank you

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

Commit messages:
 - 6960866: [Fmt-Ch] ChoiceFormat claims impossible and unimplemented functionality

Changes: https://git.openjdk.org/jdk21/pull/125/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=125&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6960866
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/125.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/125/head:pull/125

PR: https://git.openjdk.org/jdk21/pull/125

From naoto at openjdk.org  Thu Jul 13 19:17:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Jul 2023 19:17:10 GMT
Subject: <i18n dev> [jdk21] RFR: 6960866: [Fmt-Ch] ChoiceFormat claims
 impossible and unimplemented functionality
In-Reply-To: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
References: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
Message-ID: <pNupGFoQf2NbHZtnWkieRXVTjowwhW-bMOEMY69Q1fE=.3290171b-2462-4dcd-b75d-4fd620698386@github.com>

On Thu, 13 Jul 2023 18:28:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
> 
> Thank you

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/125#pullrequestreview-1529096169

From lancea at openjdk.org  Thu Jul 13 19:35:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 13 Jul 2023 19:35:20 GMT
Subject: <i18n dev> [jdk21] RFR: 6960866: [Fmt-Ch] ChoiceFormat claims
 impossible and unimplemented functionality
In-Reply-To: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
References: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
Message-ID: <7gQniErTeuFDrW2k-gnwGHF0M91r3uoSEZvU9K-F5y0=.a4e5ad25-19f1-4016-ac6e-e54d14038944@github.com>

On Thu, 13 Jul 2023 18:28:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
> 
> Thank you

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/125#pullrequestreview-1529122742

From iris at openjdk.org  Thu Jul 13 21:02:18 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 13 Jul 2023 21:02:18 GMT
Subject: <i18n dev> [jdk21] RFR: 6960866: [Fmt-Ch] ChoiceFormat claims
 impossible and unimplemented functionality
In-Reply-To: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
References: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
Message-ID: <PczmmJ9mI5_G8O8PT2hs8FuNnAk-fXJJoAqHyhB9SRk=.08b82364-9859-4cb2-8ef1-a9a5be71cb7b@github.com>

On Thu, 13 Jul 2023 18:28:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
> 
> Thank you

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/125#pullrequestreview-1529236511

From jlu at openjdk.org  Thu Jul 13 22:44:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 22:44:23 GMT
Subject: <i18n dev> [jdk21] Integrated: 6960866: [Fmt-Ch] ChoiceFormat
 claims impossible and unimplemented functionality
In-Reply-To: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
References: <otd2App8d7eBgQoieZryjQshSYcDrMAK8riNNhBQr7Y=.e566aa10-eb9c-456c-b1cf-39658f5693c0@github.com>
Message-ID: <UYWjluBODVkIfGKHRw_kkiri4f1maOdD69zGmyayn3Y=.aa55c8ea-66e5-43c3-b81c-188330ec9565@github.com>

On Thu, 13 Jul 2023 18:28:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which backports https://github.com/openjdk/jdk/commit/6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d
> 
> Thank you

This pull request has now been integrated.

Changeset: d370b96f
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/d370b96fb62c9aa2be9035ce1797acaaed764d45
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

6960866: [Fmt-Ch] ChoiceFormat claims impossible and unimplemented functionality

Reviewed-by: naoto, lancea, iris
Backport-of: 6cb9ec32a68634f0b6f7461c9dc7ef0c0e59861d

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

PR: https://git.openjdk.org/jdk21/pull/125

From jlu at openjdk.org  Thu Jul 13 23:31:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jul 2023 23:31:40 GMT
Subject: <i18n dev> RFR: 8311663: Additional refactoring of Locale tests to
 JUnit
Message-ID: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>

Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.

Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

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

Commit messages:
 - Same as prev commit
 - Remove try catch in Bug8135061.java
 - Missing import in Bug8166994.java
 - Refactor HashCodeTest.java
 - Refactor Bug6989440.java
 - Refactor ThaiGov.java
 - Refactor UseOldISOCodesTest.java
 - Refactor FilteringModeTest.java
 - Refactor Bug8159420.java
 - Refactor Bug8166994.java
 - ... and 3 more: https://git.openjdk.org/jdk/compare/292ee630...933c0312

Changes: https://git.openjdk.org/jdk/pull/14881/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311663
  Stats: 575 lines in 10 files changed: 173 ins; 233 del; 169 mod
  Patch: https://git.openjdk.org/jdk/pull/14881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14881/head:pull/14881

PR: https://git.openjdk.org/jdk/pull/14881

From naoto at openjdk.org  Fri Jul 14 22:39:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Jul 2023 22:39:15 GMT
Subject: <i18n dev> RFR: 8311663: Additional refactoring of Locale tests
 to JUnit
In-Reply-To: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
Message-ID: <CAaDFQ9BUpLzoRfEur0oaJEw3TDsTfRoT1Sxwlu2sy4=.8925a14b-aa58-45b8-be85-d6ec4dea4f1e@github.com>

On Thu, 13 Jul 2023 23:23:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
> 
> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

Thanks for the conversion, Justin. Looks good overall. Some minor comments follow.

test/jdk/java/util/Locale/Bug8135061.java line 56:

> 54:         assertNull(match, "[Locale.lookup failed on language"
> 55:                 + " range: " + ranges + " and language tags "
> 56:                 + locales + "]");

Removing try-catch will lose the information on what kind of exception was thrown

test/jdk/java/util/Locale/Bug8135061.java line 70:

> 68:         assertEquals(match.toLanguageTag(), "nv", "[Locale.lookup failed on language"
> 69:                 + " range: " + ranges + " and language tags "
> 70:                 + locales + "]");

Same as above

test/jdk/java/util/Locale/Bug8159420.java line 67:

> 65:     @BeforeAll
> 66:     static void setTurkishLocale() {
> 67:         Locale.setDefault(Locale.of("tr", "TR"));

Should the tests run under `othervm` mode?

test/jdk/java/util/Locale/Bug8179071.java line 94:

> 92:                 .map(Locale::toLanguageTag)
> 93:                 .forEach(tag -> {if(LegacyAliases.contains(tag)) {invalidTags.add(tag);}});
> 94:         assertEquals(true, invalidTags.isEmpty(),

`assertTrue()` may fit better here

test/jdk/java/util/Locale/ThaiGov.java line 51:

> 49:     // Test number formatting for thai
> 50:     @Test
> 51:     public void numberTest() throws RuntimeException {

Not your change, but this `throws` is redundant

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

PR Review: https://git.openjdk.org/jdk/pull/14881#pullrequestreview-1531097899
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264205170
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264205697
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264209622
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264216543
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1264218988

From aturbanov at openjdk.org  Mon Jul 17 09:46:56 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 17 Jul 2023 09:46:56 GMT
Subject: <i18n dev> RFR: 8312165: Fix typos in java.desktop
Message-ID: <rpXeIK3GW8zCOT6-JYx9zBdx3-6B-iFPqiX-2i5Euv8=.6b551cf1-f211-4e6f-a171-7ead0dd5d2a3@github.com>

Found many typos in java.desktop by IDEA's inspection `Proofreading | Typo`

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

Commit messages:
 - [PATCH] Fix typos in java.desktop
 - [PATCH] Fix typos in java.desktop
 - [PATCH] Fix typos in java.desktop

Changes: https://git.openjdk.org/jdk/pull/14847/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14847&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312165
  Stats: 455 lines in 187 files changed: 0 ins; 0 del; 455 mod
  Patch: https://git.openjdk.org/jdk/pull/14847.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14847/head:pull/14847

PR: https://git.openjdk.org/jdk/pull/14847

From aturbanov at openjdk.org  Mon Jul 17 11:01:03 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 17 Jul 2023 11:01:03 GMT
Subject: <i18n dev> RFR: 8311663: Additional refactoring of Locale tests
 to JUnit
In-Reply-To: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
Message-ID: <D9hUKbREEU6tQR_i57jBoAmDknti1gXsd8xytsYByKI=.19f87551-1c63-4608-a10f-c9f29e9458c1@github.com>

On Thu, 13 Jul 2023 23:23:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
> 
> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

test/jdk/java/util/Locale/Bug8179071.java line 78:

> 76:         return Stream.of(
> 77:                 Arguments.of("pa-PK", "\u0a1c\u0a28"),
> 78:                 Arguments.of("uz-AF" , "yan"),

Suggestion:

                Arguments.of("uz-AF", "yan"),

test/jdk/java/util/Locale/Bug8179071.java line 95:

> 93:                 .forEach(tag -> {if(LegacyAliases.contains(tag)) {invalidTags.add(tag);}});
> 94:         assertEquals(true, invalidTags.isEmpty(),
> 95:                 "Deprecated and Legacy tags found  " + invalidTags  + " in AvailableLocales ");

Suggestion:

                "Deprecated and Legacy tags found  " + invalidTags + " in AvailableLocales ");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265185559
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265185856

From duke at openjdk.org  Mon Jul 17 19:20:31 2023
From: duke at openjdk.org (duke)
Date: Mon, 17 Jul 2023 19:20:31 GMT
Subject: <i18n dev> Withdrawn: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset
In-Reply-To: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
Message-ID: <SxhVLs7WB2KbfVe8UjyMwj7M8xdCxfvW0s6Y67smWTI=.db85f97b-ee92-4602-8fc1-ce00a8d94ee2@github.com>

On Tue, 31 Jan 2023 15:57:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
> 
> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12346

From jlu at openjdk.org  Mon Jul 17 21:11:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:11:36 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException
Message-ID: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,

`MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent. The wording is specifically chosen as 'may throw' since whether an NPE is thrown depends on the subformat used by MessageFormat (see test example of construction with null locale and no exception thrown).

The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.

Thanks

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

Commit messages:
 - Clarify called vs invoked terminology
 - Add case of DoesNotThrow()
 - Spec and test change

Changes: https://git.openjdk.org/jdk/pull/14911/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8039165
  Stats: 149 lines in 3 files changed: 85 ins; 64 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14911/head:pull/14911

PR: https://git.openjdk.org/jdk/pull/14911

From jlu at openjdk.org  Mon Jul 17 21:31:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:31:33 GMT
Subject: <i18n dev> RFR: 8311663: Additional refactoring of Locale tests
 to JUnit [v2]
In-Reply-To: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
Message-ID: <SRrVjo_uiSSXblDnGLU0ER2qnjuPWrQEkqgYk9hBKa8=.e49a84d4-3a1d-481b-b0da-9982ec42b815@github.com>

> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
> 
> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

Justin Lu has updated the pull request incrementally with six additional commits since the last revision:

 - Review: Explicitly run via othervm and pass locale args in cmdline
 - Review: ws removal in Bug8179071.java
 - Review: remove redudant 'throws'
 - Review: Use assertTrue() in Bug8179071.java
 - Review: Revert "Same as prev commit"
   
   This reverts commit 933c0312ed2fa0f40a750e950c166b7e820df7ab.
 - Review: Revert "Remove try catch in Bug8135061.java"
   
   This reverts commit f213c74e37ed257a05a535b2c077af327343acb5.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14881/files
  - new: https://git.openjdk.org/jdk/pull/14881/files/933c0312..2b07e9f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14881&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14881&range=00-01

  Stats: 31 lines in 4 files changed: 9 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14881/head:pull/14881

PR: https://git.openjdk.org/jdk/pull/14881

From jlu at openjdk.org  Mon Jul 17 21:31:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:31:33 GMT
Subject: <i18n dev> RFR: 8311663: Additional refactoring of Locale tests
 to JUnit [v2]
In-Reply-To: <CAaDFQ9BUpLzoRfEur0oaJEw3TDsTfRoT1Sxwlu2sy4=.8925a14b-aa58-45b8-be85-d6ec4dea4f1e@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
 <CAaDFQ9BUpLzoRfEur0oaJEw3TDsTfRoT1Sxwlu2sy4=.8925a14b-aa58-45b8-be85-d6ec4dea4f1e@github.com>
Message-ID: <Dwcq_IfS7VTKaJ9lys2v3CtITaRPeGEupWw1OpR0CrU=.06351d0f-9e96-4cc6-b441-2fc66dfe92be@github.com>

On Fri, 14 Jul 2023 21:59:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Review: Explicitly run via othervm and pass locale args in cmdline
>>  - Review: ws removal in Bug8179071.java
>>  - Review: remove redudant 'throws'
>>  - Review: Use assertTrue() in Bug8179071.java
>>  - Review: Revert "Same as prev commit"
>>    
>>    This reverts commit 933c0312ed2fa0f40a750e950c166b7e820df7ab.
>>  - Review: Revert "Remove try catch in Bug8135061.java"
>>    
>>    This reverts commit f213c74e37ed257a05a535b2c077af327343acb5.
>
> test/jdk/java/util/Locale/Bug8135061.java line 56:
> 
>> 54:         assertNull(match, "[Locale.lookup failed on language"
>> 55:                 + " range: " + ranges + " and language tags "
>> 56:                 + locales + "]");
> 
> Removing try-catch will lose the information on what kind of exception was thrown

I did a second take before pushing and mistakenly removed those blocks, I knew I had left them in there originally for a reason. Fixed.

> test/jdk/java/util/Locale/ThaiGov.java line 51:
> 
>> 49:     // Test number formatting for thai
>> 50:     @Test
>> 51:     public void numberTest() throws RuntimeException {
> 
> Not your change, but this `throws` is redundant

Thanks for the review, addressed this and your other suggestions as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265919717
PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265919129

From jlu at openjdk.org  Mon Jul 17 21:31:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 17 Jul 2023 21:31:33 GMT
Subject: <i18n dev> RFR: 8311663: Additional refactoring of Locale tests
 to JUnit [v2]
In-Reply-To: <D9hUKbREEU6tQR_i57jBoAmDknti1gXsd8xytsYByKI=.19f87551-1c63-4608-a10f-c9f29e9458c1@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
 <D9hUKbREEU6tQR_i57jBoAmDknti1gXsd8xytsYByKI=.19f87551-1c63-4608-a10f-c9f29e9458c1@github.com>
Message-ID: <c6LBeQeKOpCT01bYXLioKNr4iZxttOw1JQaLTc44O7c=.9884812b-d785-44fd-89c5-530cd66c28a4@github.com>

On Mon, 17 Jul 2023 10:58:12 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Review: Explicitly run via othervm and pass locale args in cmdline
>>  - Review: ws removal in Bug8179071.java
>>  - Review: remove redudant 'throws'
>>  - Review: Use assertTrue() in Bug8179071.java
>>  - Review: Revert "Same as prev commit"
>>    
>>    This reverts commit 933c0312ed2fa0f40a750e950c166b7e820df7ab.
>>  - Review: Revert "Remove try catch in Bug8135061.java"
>>    
>>    This reverts commit f213c74e37ed257a05a535b2c077af327343acb5.
>
> test/jdk/java/util/Locale/Bug8179071.java line 95:
> 
>> 93:                 .forEach(tag -> {if(LegacyAliases.contains(tag)) {invalidTags.add(tag);}});
>> 94:         assertEquals(true, invalidTags.isEmpty(),
>> 95:                 "Deprecated and Legacy tags found  " + invalidTags  + " in AvailableLocales ");
> 
> Suggestion:
> 
>                 "Deprecated and Legacy tags found  " + invalidTags + " in AvailableLocales ");

Thanks, updated this and the other suggested WS change

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14881#discussion_r1265919052

From naoto at openjdk.org  Mon Jul 17 21:43:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 21:43:52 GMT
Subject: <i18n dev> RFR: 8311663: Additional refactoring of Locale tests
 to JUnit [v2]
In-Reply-To: <SRrVjo_uiSSXblDnGLU0ER2qnjuPWrQEkqgYk9hBKa8=.e49a84d4-3a1d-481b-b0da-9982ec42b815@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
 <SRrVjo_uiSSXblDnGLU0ER2qnjuPWrQEkqgYk9hBKa8=.e49a84d4-3a1d-481b-b0da-9982ec42b815@github.com>
Message-ID: <bSHXzRXvzNzETeoC4VQvrC38qnmw2_rjLzFX8mGzWyM=.5b231d7c-b3be-459f-bf93-1dc569a3d658@github.com>

On Mon, 17 Jul 2023 21:31:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
>> 
>> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.
>
> Justin Lu has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Review: Explicitly run via othervm and pass locale args in cmdline
>  - Review: ws removal in Bug8179071.java
>  - Review: remove redudant 'throws'
>  - Review: Use assertTrue() in Bug8179071.java
>  - Review: Revert "Same as prev commit"
>    
>    This reverts commit 933c0312ed2fa0f40a750e950c166b7e820df7ab.
>  - Review: Revert "Remove try catch in Bug8135061.java"
>    
>    This reverts commit f213c74e37ed257a05a535b2c077af327343acb5.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14881#pullrequestreview-1533749099

From naoto at openjdk.org  Mon Jul 17 22:01:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Jul 2023 22:01:11 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <19axlwyNhm52NXGVYT3UUHxQbz_GNai_DZtlOdomX9w=.2ec99ccd-7bd0-4591-80a4-85bd3632a32c@github.com>

On Mon, 17 Jul 2023 21:04:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent. The wording is specifically chosen as 'may throw' since whether an NPE is thrown depends on the subformat used by MessageFormat (see test example of construction with null locale and no exception thrown).
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

src/java.base/share/classes/java/text/MessageFormat.java line 396:

> 394:      * {@code NullPointerException} if {@code locale} is {@code null}
> 395:      * either during the creation of the {@code MessageFormat} object or later
> 396:      * when {@code format()} is called by the constructed {@code MessageFormat} object.

It looks a bit vague as it contains `may`. I think it would be clearer if it explains a bit more, e.g., it throws NPE if any of the subformats require the locale, or along with those lines. Probably the same wording is needed at `format()` and other public methods that use the `locale` field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1265940997

From prappo at openjdk.org  Mon Jul 17 23:33:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 17 Jul 2023 23:33:37 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v5]
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>

> 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.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14752/files
  - new: https://git.openjdk.org/jdk/pull/14752/files/f1ce3a10..64177d8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14752&range=03-04

  Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14752/head:pull/14752

PR: https://git.openjdk.org/jdk/pull/14752

From prappo at openjdk.org  Tue Jul 18 00:06:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 18 Jul 2023 00:06:13 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v5]
In-Reply-To: <9yQuD4s56Jx6Ks4ORj_mGSEIPOGg2YE9lua0uzhJJgs=.1f7b4918-88b9-4246-90b1-18c463cbbafb@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <aJVbzM16jOAGixCFd1Aygu6EGJus6yTc1J8fB2giRTY=.95c10d3d-4521-485f-8e9a-3eb193b181a0@github.com>
 <Sg_lMdkj5cRkH1Frtxsvezv9e77a0U2EGwyYSUYnFjU=.9b6ba5a0-36dc-4e32-8cbf-f0dba136017e@github.com>
 <s11MbjDJvP80hEZVYAyc1LscpWH9dKrAI9S2vxwNjRk=.20d85dcd-153f-415c-a575-764bb5cf0589@github.com>
 <GCRovjzQieM9Bok33SJUVasVietlsQChY9_iRKccyzY=.58f4046d-5adb-45dd-a8b2-5e26378bf59f@github.com>
 <_ygp2QHDPU7PDKWGpsL3rznNgzcjecoYBKBaOtzipnw=.04d4d6cb-ab95-4e5d-b0cc-c8c784543353@github.com>
 <tB0gdwb1wJsxS3sn9FmNwvj_2HOmm6N7WBysURUYoPM=.25f1b2f6-ea63-4022-b451-aa93eb57c04b@github.com>
 <r4-dPyuclFOYil8WAkurSA0wlwSF7wlugZX8LDa2qrE=.f7cde5c3-5882-4511-8548-10dea66522c5@github.com>
 <9yQuD4s56Jx6Ks4ORj_mGSEIPOGg2YE9lua0uzhJJgs=.1f7b4918-88b9-4246-90b1-18c463cbbafb@github.com>
Message-ID: <nPme76lZmpex7O5VazJDckxGtO8xrX78Lv3EU3iPpY8=.5cbe037f-3c36-4694-93e5-a3cda48bd23c@github.com>

On Wed, 12 Jul 2023 22:26:14 GMT, John R Rose <jrose at openjdk.org> wrote:

> Yes, it would be, because `rp` has a statically observable type, `BigInteger`. And that observation will flow across the call to the helper method.

After all, my mental model is incorrect; sigh.

I read your write-up as though once we see a static method with an Object/generic parameter, which receives a call inside that static method, our "observation of a static type" is toast.

Please provide (ideally) a few examples of a refactoring that would choke "observation of a static type", so I could correct my model.

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

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

From rriggs at openjdk.org  Tue Jul 18 13:14:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 18 Jul 2023 13:14:07 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v5]
In-Reply-To: <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>
Message-ID: <y__ota3cDIHkA3TOZP46MZzB2wC-nHTkN85lCxtwUrs=.ec64c5ba-f80f-44ee-9797-ccd3b782063e@github.com>

On Mon, 17 Jul 2023 23:33:37 GMT, Pavel Rappo <prappo 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.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1535005629

From prappo at openjdk.org  Tue Jul 18 15:15:20 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 18 Jul 2023 15:15:20 GMT
Subject: <i18n dev> Integrated: 8311188: Simplify and modernize equals and
 hashCode in java.text
In-Reply-To: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
Message-ID: <_hmWVhx75Ez5ZgquoNaMfcmYkBepIaBncxzTK5V1ysU=.91e17faa-d74e-43b7-a8f3-4783fab5fe0f@github.com>

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo <prappo 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.

This pull request has now been integrated.

Changeset: 1dfb0fb3
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1dfb0fb3e22c3616fdfa3a8249be526c44dbe890
Stats:     127 lines in 15 files changed: 29 ins; 55 del; 43 mod

8311188: Simplify and modernize equals and hashCode in java.text

Reviewed-by: lancea, naoto, rriggs

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

PR: https://git.openjdk.org/jdk/pull/14752

From lancea at openjdk.org  Tue Jul 18 15:15:19 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Jul 2023 15:15:19 GMT
Subject: <i18n dev> RFR: 8311188: Simplify and modernize equals and
 hashCode in java.text [v5]
In-Reply-To: <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>
References: <T7F1I6K-7D0Ow-PeGAlyRRpfOwrx2J6ANWEFH1iAHmA=.8a467680-a147-4c6a-ac0d-fc45d8666f22@github.com>
 <BTRuTjgqXbrydam6sjfVRIWXnwApuM-z6fS1s6drDOU=.0ae94845-0b94-45d6-8404-bc0e32ac2ebe@github.com>
Message-ID: <iTUVp7NoFNBczhWA62V2GYAnOxjMjaercHleXWLW1y0=.e0917721-3247-41c9-b8f9-7641d47c37d7@github.com>

On Mon, 17 Jul 2023 23:33:37 GMT, Pavel Rappo <prappo 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.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14752#pullrequestreview-1535273279

From liach at openjdk.org  Tue Jul 18 15:19:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Jul 2023 15:19:27 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v4]
In-Reply-To: <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>
Message-ID: <iw4XJHZ-rph9bYQ9dzUQm-hL2ZFsNDHPJZQjO9zB5Wo=.3e4e6e7e-0134-4e49-97c1-b59b7e6c4b3e@github.com>

On Thu, 29 Jun 2023 19:28:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato 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 14 additional commits since the last revision:
> 
>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>  - Use ReferencedKeyMap in place for LocaleObjectCache
>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>  - Addressing review comments
>  - Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>  - minor comment fix
>  - equals/hash fix, constructor simplification
>  - Removed Key
>  - minor fixup
>  - Use WeakHashMap
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/87a0fc50...870ec1fe

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 167:

> 165:         // can subsequently be used by the Locale instance which
> 166:         // guarantees the locale components are properly cased/interned.
> 167:         return CACHE.computeIfAbsent(new BaseLocale(language, script, region, variant),

This `computeIfAbsent` will store the non-normalized base locale as a soft key in the cache, which is undesirable. I have commented on the base patch https://github.com/openjdk/jdk/pull/14684#discussion_r1266914091 to support distinct keys for querying and storing like those in the old `LocalObjectCache`, and we can then simply use a `ReferenceKeySet` for the cache.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1266923844

From naoto at openjdk.org  Tue Jul 18 16:41:26 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jul 2023 16:41:26 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v4]
In-Reply-To: <iw4XJHZ-rph9bYQ9dzUQm-hL2ZFsNDHPJZQjO9zB5Wo=.3e4e6e7e-0134-4e49-97c1-b59b7e6c4b3e@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>
 <iw4XJHZ-rph9bYQ9dzUQm-hL2ZFsNDHPJZQjO9zB5Wo=.3e4e6e7e-0134-4e49-97c1-b59b7e6c4b3e@github.com>
Message-ID: <am8UPIo0dLThcwUsN2yb-6ErbmQidt0yyQfjDyvKkh4=.c1f0717e-0afa-45c9-8ba9-7a75a5691277@github.com>

On Tue, 18 Jul 2023 15:11:04 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Naoto Sato 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 14 additional commits since the last revision:
>> 
>>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>>  - Use ReferencedKeyMap in place for LocaleObjectCache
>>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>>  - Addressing review comments
>>  - Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>>  - minor comment fix
>>  - equals/hash fix, constructor simplification
>>  - Removed Key
>>  - minor fixup
>>  - Use WeakHashMap
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/b7933f62...870ec1fe
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 167:
> 
>> 165:         // can subsequently be used by the Locale instance which
>> 166:         // guarantees the locale components are properly cased/interned.
>> 167:         return CACHE.computeIfAbsent(new BaseLocale(language, script, region, variant),
> 
> This `computeIfAbsent` will store the non-normalized base locale as a soft key in the cache, which is undesirable. I have commented on the base patch https://github.com/openjdk/jdk/pull/14684#discussion_r1266914091 to support distinct keys for querying and storing like those in the old `LocalObjectCache`, and we can then simply use a `ReferenceKeySet` for the cache.

The reason I used non-normalized base locale as the key was that normalizing (interning) was slower than comparing the key. I would have to double check, and see if the distinct normalized key is faster.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1267037551

From jlu at openjdk.org  Tue Jul 18 20:48:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Jul 2023 20:48:13 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException [v2]
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <yUwg4u4-pbTS8osxbRBNOkDfm2KfX1OURICTJQRh05U=.a595371c-8939-436e-8e6a-5a725cbf5277@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent. The wording is specifically chosen as 'may throw' since whether an NPE is thrown depends on the subformat used by MessageFormat (see test example of construction with null locale and no exception thrown).
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Slight wording adjustment
 - Review: Explicitly declare when NPE thrown instead of 'may'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14911/files
  - new: https://git.openjdk.org/jdk/pull/14911/files/05ac9193..4092e3ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=00-01

  Stats: 14 lines in 2 files changed: 10 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14911/head:pull/14911

PR: https://git.openjdk.org/jdk/pull/14911

From jlu at openjdk.org  Tue Jul 18 20:59:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 18 Jul 2023 20:59:43 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException [v2]
In-Reply-To: <19axlwyNhm52NXGVYT3UUHxQbz_GNai_DZtlOdomX9w=.2ec99ccd-7bd0-4591-80a4-85bd3632a32c@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
 <19axlwyNhm52NXGVYT3UUHxQbz_GNai_DZtlOdomX9w=.2ec99ccd-7bd0-4591-80a4-85bd3632a32c@github.com>
Message-ID: <C-fNc4s5q_E9LY-4LdNBHklGaEDsqfWKeqh7vn1GgU8=.daddeacc-abbc-4696-b8e6-48d314f6c98f@github.com>

On Mon, 17 Jul 2023 21:54:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Slight wording adjustment
>>  - Review: Explicitly declare when NPE thrown instead of 'may'
>
> src/java.base/share/classes/java/text/MessageFormat.java line 396:
> 
>> 394:      * {@code NullPointerException} if {@code locale} is {@code null}
>> 395:      * either during the creation of the {@code MessageFormat} object or later
>> 396:      * when {@code format()} is called by the constructed {@code MessageFormat} object.
> 
> It looks a bit vague as it contains `may`. I think it would be clearer if it explains a bit more, e.g., it throws NPE if any of the subformats require the locale, or along with those lines. Probably the same wording is needed at `format()` and other public methods that use the `locale` field.

The only other public methods that use `locale` are setLocale(), getLocale(), toString(), and equals(). In all of these cases I don't believe if a MessageFormat that was created with a null locale (and did not throw NPE) calls them, a NPE will occur in any case.

Thus I have updated the spec to not use 'may' and explicitly state NPE is thrown if a subformat is localized and needed by the MessageFormat.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1267298674

From naoto at openjdk.org  Tue Jul 18 22:15:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Jul 2023 22:15:43 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException [v2]
In-Reply-To: <yUwg4u4-pbTS8osxbRBNOkDfm2KfX1OURICTJQRh05U=.a595371c-8939-436e-8e6a-5a725cbf5277@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
 <yUwg4u4-pbTS8osxbRBNOkDfm2KfX1OURICTJQRh05U=.a595371c-8939-436e-8e6a-5a725cbf5277@github.com>
Message-ID: <TkjfooL3oTp-53EAxHoltO3ln1VugGydMJb9zVKELMY=.fc04ca6e-16f2-43e6-921e-9989f0a35c06@github.com>

On Tue, 18 Jul 2023 20:48:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
>> 
>> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent. The wording is specifically chosen as 'may throw' since whether an NPE is thrown depends on the subformat used by MessageFormat (see test example of construction with null locale and no exception thrown).
>> 
>> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
>> 
>> Thanks
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Slight wording adjustment
>  - Review: Explicitly declare when NPE thrown instead of 'may'

src/java.base/share/classes/java/text/MessageFormat.java line 398:

> 396:      * when {@code format()} is called by the constructed {@code MessageFormat}
> 397:      * instance and the implementation utilizes a subformat that requires
> 398:      * localization.

Sorry for the nitpick, but since localization itself is not a requirement, `locale-dependent subformat` would read better to me. (and wherever `localized` is used)

src/java.base/share/classes/java/text/MessageFormat.java line 407:

> 405:      * @throws    NullPointerException This method throws a
> 406:      *            {@code NullPointerException} if {@code locale} is {@code null}
> 407:      *            and a localized subformat is used.

NPE throws tags should be combined. Applies to other locations too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1267346080
PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1267347900

From jlu at openjdk.org  Wed Jul 19 18:46:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Jul 2023 18:46:44 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException [v3]
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <dLCFeLtinyQRS-pJpV6MSEb5ZY8FDfQ71MLAYoV75rE=.fd19229a-eb0a-4353-8e35-2c9fd06fd2d6@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent.
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Combine throws for constructor
 - Review: Combine throws and re-word localized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14911/files
  - new: https://git.openjdk.org/jdk/pull/14911/files/4092e3ad..8fd94758

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=01-02

  Stats: 14 lines in 1 file changed: 0 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14911/head:pull/14911

PR: https://git.openjdk.org/jdk/pull/14911

From jlu at openjdk.org  Wed Jul 19 18:46:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Jul 2023 18:46:46 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException [v2]
In-Reply-To: <TkjfooL3oTp-53EAxHoltO3ln1VugGydMJb9zVKELMY=.fc04ca6e-16f2-43e6-921e-9989f0a35c06@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
 <yUwg4u4-pbTS8osxbRBNOkDfm2KfX1OURICTJQRh05U=.a595371c-8939-436e-8e6a-5a725cbf5277@github.com>
 <TkjfooL3oTp-53EAxHoltO3ln1VugGydMJb9zVKELMY=.fc04ca6e-16f2-43e6-921e-9989f0a35c06@github.com>
Message-ID: <vO4gIMeijrpqQfxoqsWtSt8zg1NXFIlaUry9x3L33xM=.918eed16-f796-4c5a-9880-0ca9a9f71ba1@github.com>

On Tue, 18 Jul 2023 22:09:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Slight wording adjustment
>>  - Review: Explicitly declare when NPE thrown instead of 'may'
>
> src/java.base/share/classes/java/text/MessageFormat.java line 407:
> 
>> 405:      * @throws    NullPointerException This method throws a
>> 406:      *            {@code NullPointerException} if {@code locale} is {@code null}
>> 407:      *            and a localized subformat is used.
> 
> NPE throws tags should be combined. Applies to other locations too.

Thanks for the follow up review, I have fixed this and the 'localized' wording. I have also updated the CSR to reflect the most recent changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14911#discussion_r1268509743

From jlu at openjdk.org  Wed Jul 19 19:41:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Jul 2023 19:41:57 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException [v4]
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <cBtznTXqufCCFh3wp1dQTQ0hLO7Aav0kus3FfUb4KRQ=.989dfca0-ec97-4a66-9d06-a00a34c082af@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent.
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Account for setLocale()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14911/files
  - new: https://git.openjdk.org/jdk/pull/14911/files/8fd94758..b075f5d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14911&range=02-03

  Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14911/head:pull/14911

PR: https://git.openjdk.org/jdk/pull/14911

From naoto at openjdk.org  Wed Jul 19 19:51:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Jul 2023 19:51:52 GMT
Subject: <i18n dev> RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException [v4]
In-Reply-To: <cBtznTXqufCCFh3wp1dQTQ0hLO7Aav0kus3FfUb4KRQ=.989dfca0-ec97-4a66-9d06-a00a34c082af@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
 <cBtznTXqufCCFh3wp1dQTQ0hLO7Aav0kus3FfUb4KRQ=.989dfca0-ec97-4a66-9d06-a00a34c082af@github.com>
Message-ID: <Zz1PMhNeX-UQNQfp8eIzXnwoElY1FsSIigf2inXoybQ=.4ec5a81c-c29d-48d6-9d57-85de63421984@github.com>

On Wed, 19 Jul 2023 19:41:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
>> 
>> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent.
>> 
>> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
>> 
>> Thanks
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Account for setLocale()

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14911#pullrequestreview-1537916353

From jlu at openjdk.org  Wed Jul 19 20:25:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Jul 2023 20:25:54 GMT
Subject: <i18n dev> Integrated: 8311663: Additional refactoring of Locale
 tests to JUnit
In-Reply-To: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
References: <9ljXcDZUjo6DzYJd_asojh4YJVvdIk3ilQmMvtMugqY=.1463fa0d-07f6-42eb-a327-18850dd69b17@github.com>
Message-ID: <G5Yt9jVSv_JPKXHWwV_jWbWyyuB722-B7XCghWgXSo4=.1f89711e-4cd1-4991-9a08-4ca7cae88808@github.com>

On Thu, 13 Jul 2023 23:23:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors more java.util.Locale tests to JUnit with some minor cleanup as well.
> 
> Although some of the files could benefit from being renamed bugNNNNNNN to something more descriptive, this makes reviewing harder, and will be handled separately.

This pull request has now been integrated.

Changeset: 71cac8ce
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71cac8ce47b69a2b78d54cbceb0f0510e5ea4cdc
Stats:     549 lines in 10 files changed: 159 ins; 217 del; 173 mod

8311663: Additional refactoring of Locale tests to JUnit

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/14881

From duke at openjdk.org  Thu Jul 20 08:26:59 2023
From: duke at openjdk.org (duke)
Date: Thu, 20 Jul 2023 08:26:59 GMT
Subject: <i18n dev> Withdrawn: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <uACzUIIlGzNNhCXOuGY45jzmPgqJjrgvuKTTpFZ0Ptg=.0d30a954-b573-4d4a-bdee-92d1fcd37ccc@github.com>

On Tue, 23 May 2023 23:16:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/14110

From jlu at openjdk.org  Tue Jul 25 18:30:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Jul 2023 18:30:00 GMT
Subject: <i18n dev> Integrated: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException
In-Reply-To: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
References: <fVYkLO4UlRRazlV9NAgjtZPYxmGdHKXtW3zhBYXRE4k=.8a9c6058-a3d3-48b4-b1fb-0f12a0ce3e99@github.com>
Message-ID: <Q54LXCRu_Q4ym91Ai0dcPfsM6l_H0NxBVcCy6HDCYXk=.73288791-ff20-4d71-afd7-358e7a3db81e@github.com>

On Mon, 17 Jul 2023 21:04:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8312197) which updates the javadoc for the constructor of MessageFormat regarding a `null` locale,
> 
> `MessageFormat` when created with a `null` locale may throw a `NullPointerException` either during the object creation, or later when `format()` is called by the `MessageFormat` object (test file has examples of both). This change updates the specification of MessageFormat to make this apparent.
> 
> The test for this change was merged with `Bug6481179.java` into `MessageFormatExceptions.java` (As they both test exceptions). In addition, some other exception testing regarding MessageFormat was added.
> 
> Thanks

This pull request has now been integrated.

Changeset: c6396dce
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6396dceb9a64578d5b335af27ad1d968190a1fa
Stats:     164 lines in 3 files changed: 97 ins; 64 del; 3 mod

8039165: [Doc] MessageFormat null locale generates NullPointerException

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/14911

From jlu at openjdk.org  Wed Jul 26 07:18:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Jul 2023 07:18:22 GMT
Subject: <i18n dev> RFR: 8312416: Tests in Locale should have more
 descriptive names
Message-ID: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>

Please review this change which renames tests for Locale from `bugNNNNNNN.java` to something more descriptive.

In addition to the name changes, accompanying copyright year, name usage within the test, and other minor changes were included. The test `bug4123285.java` was also removed, as it was never actually ran and java.applet.Applet is deprecated and marked for removal.

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

Commit messages:
 - Copyright years, import cleanup, name within file, etc.
 - Rename files and remove unusued test files

Changes: https://git.openjdk.org/jdk/pull/15032/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15032&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312416
  Stats: 265 lines in 16 files changed: 93 ins; 138 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/15032.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15032/head:pull/15032

PR: https://git.openjdk.org/jdk/pull/15032

From jlu at openjdk.org  Wed Jul 26 07:44:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Jul 2023 07:44:58 GMT
Subject: <i18n dev> RFR: 8312411: MessageFormat.formatToCharacterIterator()
 can be improved
Message-ID: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>

Please review this change which makes `MessageFormat.formatToCharacterIterator` fail fast(er). The return statement is also modified to call  toArray() as `toArray(new T[0])` over `toArray(new T[size])`.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15035/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312411
  Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15035/head:pull/15035

PR: https://git.openjdk.org/jdk/pull/15035

From lancea at openjdk.org  Wed Jul 26 19:23:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 26 Jul 2023 19:23:39 GMT
Subject: <i18n dev> RFR: 8312416: Tests in Locale should have more
 descriptive names
In-Reply-To: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
References: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
Message-ID: <j4ljx72CpCaZZFV4nV7j-xVjH04IRAySijrYL49KpV4=.03b6aee1-4055-4828-a728-16ac51ea537d@github.com>

On Wed, 26 Jul 2023 07:11:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which renames tests for Locale from `bugNNNNNNN.java` to something more descriptive.
> 
> In addition to the name changes, accompanying copyright year, name usage within the test, and other minor changes were included. The test `bug4123285.java` was also removed, as it was never actually ran and java.applet.Applet is deprecated and marked for removal.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15032#pullrequestreview-1548440407

From naoto at openjdk.org  Wed Jul 26 19:49:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Jul 2023 19:49:50 GMT
Subject: <i18n dev> RFR: 8312416: Tests in Locale should have more
 descriptive names
In-Reply-To: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
References: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
Message-ID: <nNE0HY8PwyYXQBHPUGcBV6-rMr4UZIMZPLmQF44P2M4=.487ec6b2-98f3-47d2-8137-1afc516de1f5@github.com>

On Wed, 26 Jul 2023 07:11:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which renames tests for Locale from `bugNNNNNNN.java` to something more descriptive.
> 
> In addition to the name changes, accompanying copyright year, name usage within the test, and other minor changes were included. The test `bug4123285.java` was also removed, as it was never actually ran and java.applet.Applet is deprecated and marked for removal.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15032#pullrequestreview-1548484877

From naoto at openjdk.org  Wed Jul 26 19:50:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Jul 2023 19:50:41 GMT
Subject: <i18n dev> RFR: 8312411:
 MessageFormat.formatToCharacterIterator() can be improved
In-Reply-To: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>
References: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>
Message-ID: <zuRoZHwbtAjoOYs9QO_OTyQgxmNzgM6FBDw4JJ9Ewy8=.52699377-c7c0-4009-93c4-8e6ab3390dbf@github.com>

On Wed, 26 Jul 2023 07:39:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which makes `MessageFormat.formatToCharacterIterator` fail fast(er). The return statement is also modified to call  toArray() as `toArray(new T[0])` over `toArray(new T[size])`.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15035#pullrequestreview-1548486880

From jjiang at openjdk.org  Thu Jul 27 06:52:48 2023
From: jjiang at openjdk.org (John Jiang)
Date: Thu, 27 Jul 2023 06:52:48 GMT
Subject: <i18n dev> RFR: 8313231: Redundant if statement in ZoneInfoFile
Message-ID: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>

if (i < savingsInstantTransitions.length) {
    // javazic writes the last GMT offset into index 0!
    if (i < savingsInstantTransitions.length) {
        offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
        nOffsets = 1;
    }
    ...
}


The second if statement looks unnecessary.

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

Commit messages:
 - 8313231: Redundant if statement in ZoneInfoFile

Changes: https://git.openjdk.org/jdk/pull/15052/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15052&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313231
  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15052/head:pull/15052

PR: https://git.openjdk.org/jdk/pull/15052

From jiefu at openjdk.org  Thu Jul 27 07:07:40 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 27 Jul 2023 07:07:40 GMT
Subject: <i18n dev> RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
Message-ID: <_SPmmWS-rmB5DVb-0_3zYEV5VARVrGncaK2qiwOrcBc=.9ecdb2e3-de41-40a4-9b41-ee04d909b280@github.com>

On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang <jjiang at openjdk.org> wrote:

> if (i < savingsInstantTransitions.length) {
>     // javazic writes the last GMT offset into index 0!
>     if (i < savingsInstantTransitions.length) {
>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>         nOffsets = 1;
>     }
>     ...
> }
> 
> 
> The second if statement looks unnecessary.

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15052#pullrequestreview-1549140091

From prappo at openjdk.org  Thu Jul 27 11:03:40 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 27 Jul 2023 11:03:40 GMT
Subject: <i18n dev> RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
Message-ID: <WkXEKK2noE080KzBMxfg-2xDGqUglB_zA267OpdC6gY=.fa7eeba9-2bb7-4f36-8c5e-20137a0ff9a1@github.com>

On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang <jjiang at openjdk.org> wrote:

> if (i < savingsInstantTransitions.length) {
>     // javazic writes the last GMT offset into index 0!
>     if (i < savingsInstantTransitions.length) {
>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>         nOffsets = 1;
>     }
>     ...
> }
> 
> 
> The second if statement looks unnecessary.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 471:

> 469:             if (i < savingsInstantTransitions.length) {
> 470:                 // javazic writes the last GMT offset into index 0!
> 471:                 if (i < savingsInstantTransitions.length) {

Even my IDE flags it as always true. While it surely is redundant, I wonder if some other check was intended instead. @jodastephen?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15052#discussion_r1276120009

From shade at openjdk.org  Fri Jul 28 08:56:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jul 2023 08:56:08 GMT
Subject: <i18n dev> RFR: 8313307: java/util/Formatter/Padding.java fails on
 some Locales
Message-ID: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>

Fails like this:


$ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java

...
STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>


Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/15066/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313307
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15066/head:pull/15066

PR: https://git.openjdk.org/jdk/pull/15066

From jlu at openjdk.org  Fri Jul 28 16:30:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Jul 2023 16:30:01 GMT
Subject: <i18n dev> Integrated: 8312416: Tests in Locale should have more
 descriptive names
In-Reply-To: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
References: <PrykfUm6DeNNoi2uQ9YR74Ae5Y0Fcn7S1-45ola7Qeo=.d158464f-ed6c-4cec-bcdd-2c998bc0934d@github.com>
Message-ID: <SvVGCvpozhKA3NBVo2W0CYMRSeAmneCopO8pnQ2Ba5I=.43a8c303-e3a9-413c-8bfa-004d40432383@github.com>

On Wed, 26 Jul 2023 07:11:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which renames tests for Locale from `bugNNNNNNN.java` to something more descriptive.
> 
> In addition to the name changes, accompanying copyright year, name usage within the test, and other minor changes were included. The test `bug4123285.java` was also removed, as it was never actually ran and java.applet.Applet is deprecated and marked for removal.

This pull request has now been integrated.

Changeset: a9a3463a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9a3463afb33b9df4cbf64d1866255bff638824f
Stats:     265 lines in 16 files changed: 93 ins; 138 del; 34 mod

8312416: Tests in Locale should have more descriptive names

Reviewed-by: lancea, naoto

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

PR: https://git.openjdk.org/jdk/pull/15032

From jlu at openjdk.org  Fri Jul 28 16:47:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Jul 2023 16:47:43 GMT
Subject: <i18n dev> RFR: 8313307: java/util/Formatter/Padding.java fails
 on some Locales
In-Reply-To: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
Message-ID: <FBzz30yUkDXmLzvheZkPF9EEW_kwWFyucP1ygAAOS3M=.44e4e387-f0d1-4c39-8df8-7ef171ac1aa6@github.com>

On Fri, 28 Jul 2023 08:49:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

LGTM

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15066#pullrequestreview-1552500764

From naoto at openjdk.org  Fri Jul 28 16:59:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Jul 2023 16:59:41 GMT
Subject: <i18n dev> RFR: 8313307: java/util/Formatter/Padding.java fails
 on some Locales
In-Reply-To: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
Message-ID: <z8Z6tshLWFUpyMQnXUuZuadiJOdDwStWuaEeUn5k0UA=.8cbca214-08a0-47b6-8ad7-0681f75bae39@github.com>

On Fri, 28 Jul 2023 08:49:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

test/jdk/java/util/Formatter/Padding.java line 312:

> 310:     @MethodSource
> 311:     void padding(String expected, String format, Object value) {
> 312:         assertEquals(expected, String.format(Locale.ROOT, format, value));

I suggest using `Locale.US` instead of `Locale.ROOT`. Although it works, `Locale.ROOT` is an invariant locale where theoretically you cannot assume the decimal point is a period. Using `Locale.US` assures that assumption, and also aligns with other similar test cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15066#discussion_r1277788433

From shade at openjdk.org  Fri Jul 28 17:13:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jul 2023 17:13:54 GMT
Subject: <i18n dev> RFR: 8313307: java/util/Formatter/Padding.java fails
 on some Locales [v2]
In-Reply-To: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
Message-ID: <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Change to Locale.US

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15066/files
  - new: https://git.openjdk.org/jdk/pull/15066/files/97084428..eaca173c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15066&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15066&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15066/head:pull/15066

PR: https://git.openjdk.org/jdk/pull/15066

From shade at openjdk.org  Fri Jul 28 17:13:55 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Jul 2023 17:13:55 GMT
Subject: <i18n dev> RFR: 8313307: java/util/Formatter/Padding.java fails
 on some Locales [v2]
In-Reply-To: <z8Z6tshLWFUpyMQnXUuZuadiJOdDwStWuaEeUn5k0UA=.8cbca214-08a0-47b6-8ad7-0681f75bae39@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
 <z8Z6tshLWFUpyMQnXUuZuadiJOdDwStWuaEeUn5k0UA=.8cbca214-08a0-47b6-8ad7-0681f75bae39@github.com>
Message-ID: <oSqdWC9_f88kE4RcNfwyTHyk7Z4uYSbi32G0JocnJGA=.57960543-a960-438b-bab1-83f08c471c9e@github.com>

On Fri, 28 Jul 2023 16:53:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change to Locale.US
>
> test/jdk/java/util/Formatter/Padding.java line 312:
> 
>> 310:     @MethodSource
>> 311:     void padding(String expected, String format, Object value) {
>> 312:         assertEquals(expected, String.format(Locale.ROOT, format, value));
> 
> I suggest using `Locale.US` instead of `Locale.ROOT`. Although it works, `Locale.ROOT` is an invariant locale where theoretically you cannot assume the decimal point is a period. Using `Locale.US` assures that assumption, and also aligns with other similar test cases.

Sure, changed to `Locale.US` in new commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15066#discussion_r1277801468

From naoto at openjdk.org  Fri Jul 28 17:19:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Jul 2023 17:19:42 GMT
Subject: <i18n dev> RFR: 8313307: java/util/Formatter/Padding.java fails
 on some Locales [v2]
In-Reply-To: <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
 <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>
Message-ID: <T1qDVaP6XmU0-CX4eJeFqK6EGEyqvoHMKBZzkq09qFY=.97ed1876-3e38-4b59-aeec-5a840e1cc274@github.com>

On Fri, 28 Jul 2023 17:13:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Fails like this:
>> 
>> 
>> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
>> 
>> ...
>> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
>> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
>> 
>> 
>> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to Locale.US

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15066#pullrequestreview-1552546716

From jlu at openjdk.org  Fri Jul 28 17:37:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Jul 2023 17:37:01 GMT
Subject: <i18n dev> Integrated: 8312411:
 MessageFormat.formatToCharacterIterator() can be improved
In-Reply-To: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>
References: <SvBOR63sGUuLf0dWrmAV9vbyHNN2mf3wZIefKffPGl0=.05694f16-665d-407c-87b8-6b19041cf2d3@github.com>
Message-ID: <SpjLu1vVOIPkbXXaSWkcgDmz_P6rvgPtxVfN71_NIjU=.79bdce13-87ab-4386-8b5a-601a69e8ff1a@github.com>

On Wed, 26 Jul 2023 07:39:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which makes `MessageFormat.formatToCharacterIterator` fail fast(er). The return statement is also modified to call  toArray() as `toArray(new T[0])` over `toArray(new T[size])`.

This pull request has now been integrated.

Changeset: 23755f90
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23755f90c9fb69b0ddad0cdfcdf8add309b1d845
Stats:     7 lines in 1 file changed: 1 ins; 5 del; 1 mod

8312411: MessageFormat.formatToCharacterIterator() can be improved

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/15035

From scolebourne at openjdk.org  Mon Jul 31 07:13:43 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 31 Jul 2023 07:13:43 GMT
Subject: <i18n dev> RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
Message-ID: <w4MO1cUT1BGF6AwXNxGw6DfLkjPmRLF6MS2Z0CP8hbw=.f8943550-2c74-46dc-92e7-3e86a6f0c24c@github.com>

On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang <jjiang at openjdk.org> wrote:

> if (i < savingsInstantTransitions.length) {
>     // javazic writes the last GMT offset into index 0!
>     if (i < savingsInstantTransitions.length) {
>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>         nOffsets = 1;
>     }
>     ...
> }
> 
> 
> The second if statement looks unnecessary.

Marked as reviewed by scolebourne (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/15052#pullrequestreview-1554092886

From scolebourne at openjdk.org  Mon Jul 31 07:13:45 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Mon, 31 Jul 2023 07:13:45 GMT
Subject: <i18n dev> RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <WkXEKK2noE080KzBMxfg-2xDGqUglB_zA267OpdC6gY=.fa7eeba9-2bb7-4f36-8c5e-20137a0ff9a1@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
 <WkXEKK2noE080KzBMxfg-2xDGqUglB_zA267OpdC6gY=.fa7eeba9-2bb7-4f36-8c5e-20137a0ff9a1@github.com>
Message-ID: <7pmFTOthufJofV1gsoIeOVdc5FqkdZSl9DeSbsgHRa0=.e9eaef28-76b1-4f75-936d-b1aabeb88f25@github.com>

On Thu, 27 Jul 2023 11:01:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> if (i < savingsInstantTransitions.length) {
>>     // javazic writes the last GMT offset into index 0!
>>     if (i < savingsInstantTransitions.length) {
>>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>>         nOffsets = 1;
>>     }
>>     ...
>> }
>> 
>> 
>> The second if statement looks unnecessary.
>
> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 471:
> 
>> 469:             if (i < savingsInstantTransitions.length) {
>> 470:                 // javazic writes the last GMT offset into index 0!
>> 471:                 if (i < savingsInstantTransitions.length) {
> 
> Even my IDE flags it as always true. While it surely is redundant, I wonder if some other check was intended instead. @jodastephen?

I'm not sure this is my code - I certainly don't remember it. This PR causes no effective change but be slightly neater, so I guess I approve the PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15052#discussion_r1278874277

From jjiang at openjdk.org  Mon Jul 31 07:48:44 2023
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 31 Jul 2023 07:48:44 GMT
Subject: <i18n dev> RFR: 8313231: Redundant if statement in ZoneInfoFile
In-Reply-To: <w4MO1cUT1BGF6AwXNxGw6DfLkjPmRLF6MS2Z0CP8hbw=.f8943550-2c74-46dc-92e7-3e86a6f0c24c@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
 <w4MO1cUT1BGF6AwXNxGw6DfLkjPmRLF6MS2Z0CP8hbw=.f8943550-2c74-46dc-92e7-3e86a6f0c24c@github.com>
Message-ID: <xM_hTPE2FiPCzI7F-xvVkDXBSNMjsHM-2uihF22lMbE=.13fb363f-63a2-4288-915d-33876b78f9aa@github.com>

On Mon, 31 Jul 2023 07:11:24 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> if (i < savingsInstantTransitions.length) {
>>     // javazic writes the last GMT offset into index 0!
>>     if (i < savingsInstantTransitions.length) {
>>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>>         nOffsets = 1;
>>     }
>>     ...
>> }
>> 
>> 
>> The second if statement looks unnecessary.
>
> Marked as reviewed by scolebourne (Author).

@jodastephen @DamonFool @pavelrappo 
Thanks for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/15052#issuecomment-1657847007

From jjiang at openjdk.org  Mon Jul 31 07:53:55 2023
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 31 Jul 2023 07:53:55 GMT
Subject: <i18n dev> Integrated: 8313231: Redundant if statement in
 ZoneInfoFile
In-Reply-To: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
References: <X0UHepnjWxxL1aSUtBHFQ3HFlC2PGxzC8ussLHzboLE=.7f112e66-f9f0-4fba-85ff-e8f0fe1a8aec@github.com>
Message-ID: <VypUq7JamGZQQyfsFDccrZ3JmDkPMtiy4z6zcX4WNlw=.56b49ee4-48b4-4116-8c30-222367d39770@github.com>

On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang <jjiang at openjdk.org> wrote:

> if (i < savingsInstantTransitions.length) {
>     // javazic writes the last GMT offset into index 0!
>     if (i < savingsInstantTransitions.length) {
>         offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>         nOffsets = 1;
>     }
>     ...
> }
> 
> 
> The second if statement looks unnecessary.

This pull request has now been integrated.

Changeset: f8c2b7fe
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8c2b7fee101d66107704b3ee464737c5ccdc13a
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8313231: Redundant if statement in ZoneInfoFile

Reviewed-by: jiefu, scolebourne

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

PR: https://git.openjdk.org/jdk/pull/15052

From shade at openjdk.org  Mon Jul 31 08:37:58 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 31 Jul 2023 08:37:58 GMT
Subject: <i18n dev> RFR: 8313307: java/util/Formatter/Padding.java fails
 on some Locales [v2]
In-Reply-To: <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
 <n6-76f0BzHFEKRERy68N-jTy_zEoArwe6jeczkYCHhs=.89bb7415-fd8c-494d-8749-584e4eb19129@github.com>
Message-ID: <yBwYg7E4VaZsHTOb3-FviM2p1YEfJyfYuEs1SFeTpyE=.336380f3-332e-4a05-b9b7-0232a5659929@github.com>

On Fri, 28 Jul 2023 17:13:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Fails like this:
>> 
>> 
>> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
>> 
>> ...
>> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
>> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
>> 
>> 
>> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to Locale.US

Thank you all!

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

PR Comment: https://git.openjdk.org/jdk/pull/15066#issuecomment-1657917894

From shade at openjdk.org  Mon Jul 31 08:37:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 31 Jul 2023 08:37:59 GMT
Subject: <i18n dev> Integrated: 8313307: java/util/Formatter/Padding.java
 fails on some Locales
In-Reply-To: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
References: <EJT_Qa4_qFPxOODAVPTFLcsryicQmATmyXfPF4JThao=.66aab21f-de24-443c-bc44-e7fbca48cebd@github.com>
Message-ID: <HYhRy-jeW34MAy0f80B7f0xFJx35lNF8NCBEJvptEPw=.e0745eb6-b919-4d0c-87dc-93c790f884e3@github.com>

On Fri, 28 Jul 2023 08:49:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Fails like this:
> 
> 
> $ CONF=macosx-aarch64-server-fastdebug make images test TEST=java/util/Formatter/Padding.java
> 
> ...
> STARTED Padding::padding '[216] -0000001.2, % 010.1f, -1.2'
> org.opentest4j.AssertionFailedError: expected: <-0000001.2> but was: <-0000001,2>
> 
> 
> Looks like a locale problem in test, so the simplest fix is to ask for a neutral Locale there.

This pull request has now been integrated.

Changeset: 408987e1
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/408987e1ca9a42db8019b1bd7e52f85607975dde
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8313307: java/util/Formatter/Padding.java fails on some Locales

Reviewed-by: jlu, naoto

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

PR: https://git.openjdk.org/jdk/pull/15066

From jlu at openjdk.org  Mon Jul 31 21:20:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 31 Jul 2023 21:20:59 GMT
Subject: <i18n dev> [jdk21] RFR: 8039165: [Doc] MessageFormat null locale
 generates NullPointerException
Message-ID: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>

Please review this change which contains a backport of commit [c6396dce](https://github.com/openjdk/jdk/commit/c6396dceb9a64578d5b335af27ad1d968190a1fa) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This PR is a java.text doc/test-only change.

The commit being backported was authored by Justin Lu on 25 Jul 2023 and was reviewed by Naoto Sato.

Thanks!

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

Commit messages:
 - Backport c6396dceb9a64578d5b335af27ad1d968190a1fa

Changes: https://git.openjdk.org/jdk21/pull/154/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8039165
  Stats: 164 lines in 3 files changed: 97 ins; 64 del; 3 mod
  Patch: https://git.openjdk.org/jdk21/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/154/head:pull/154

PR: https://git.openjdk.org/jdk21/pull/154

From naoto at openjdk.org  Mon Jul 31 21:29:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 31 Jul 2023 21:29:56 GMT
Subject: <i18n dev> [jdk21] RFR: 8039165: [Doc] MessageFormat null
 locale generates NullPointerException
In-Reply-To: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>
References: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>
Message-ID: <rGO2QeiL9_IzjuSHcx8ojegiGNCJ5gAjNYPZTu24r0Q=.e3822510-3e48-4a98-aad1-ca60b53c623b@github.com>

On Mon, 31 Jul 2023 21:13:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which contains a backport of commit [c6396dce](https://github.com/openjdk/jdk/commit/c6396dceb9a64578d5b335af27ad1d968190a1fa) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This PR is a java.text doc/test-only change.
> 
> The commit being backported was authored by Justin Lu on 25 Jul 2023 and was reviewed by Naoto Sato.
> 
> Thanks!

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/154#pullrequestreview-1555801280