From duke at openjdk.org  Thu Jun  1 06:58:32 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 1 Jun 2023 06:58:32 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently [v2]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <S0qfvrxlKXqzLuzbqOeqBaqMR0GKEkwXPbpEbk1_sM8=.30ce4d14-d37d-4882-976e-71ba2420ed01@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8289220: [Shenandoah] TestAllocObjectArrays fails intermittently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/31137f12..51883706

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

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

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

From alanb at openjdk.org  Thu Jun  1 07:12:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 07:12:09 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently [v2]
In-Reply-To: <S0qfvrxlKXqzLuzbqOeqBaqMR0GKEkwXPbpEbk1_sM8=.30ce4d14-d37d-4882-976e-71ba2420ed01@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <S0qfvrxlKXqzLuzbqOeqBaqMR0GKEkwXPbpEbk1_sM8=.30ce4d14-d37d-4882-976e-71ba2420ed01@github.com>
Message-ID: <YCSkW6VOaaFikTA9yi_s_HlFx92HtwSzqujLvEiGM6s=.54d65565-32eb-49c8-83b7-33b498a5127b@github.com>

On Thu, 1 Jun 2023 06:58:32 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: [Shenandoah] TestAllocObjectArrays fails intermittently

I've moved the issue to core-libs/java.util:i18n and change the title of the JBS issue to make it clearer what this is about. Can you adjust the PR description too as this is not ShenandoahGC issue.

@naotoj We might want to think about adding more tests in this area to ensure that the locale cache is stress tested.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1571481539

From duke at openjdk.org  Thu Jun  1 08:58:23 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 1 Jun 2023 08:58:23 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently [v3]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/51883706..a09f1b6f

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

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

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

From duke at openjdk.org  Thu Jun  1 09:06:09 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 1 Jun 2023 09:06:09 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <VW0d0G5A5DXLwKTartQijiUdmG2H19-q_PY_iB55DeE=.23d70c40-6a5a-40d2-b060-9dee7fbffe75@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

I've done basic testing jtreg tier1-3 and partial shenandoah testing with vmoptions `-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, the results are all OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1571644464

From naoto at openjdk.org  Thu Jun  1 16:28:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Jun 2023 16:28:06 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <EALFii1S4iLn4SWLDT9AB7R2Ey_w5tMpMEtTi5Jc-wk=.75360c13-4d55-4aa5-a11b-494c1eed7741@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

Those SoftReference caches are introduced with this change: https://bugs.openjdk.org/browse/JDK-8196869, and there is a stress test added for it: test/jdk/java/util/Locale/SoftKeys.java
@sunny868 Would you be able to add a JMH test to make sure that your change would not affect the startup time?
@cl4es would you take a look at this change?
Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1572362241

From naoto at openjdk.org  Thu Jun  1 21:46:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Jun 2023 21:46:13 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <eIjbrsmBz485KHAyRmOWdM_LUC33JSNTnR8uHFrA17o=.8431098a-739e-4530-97da-a4133c622d3a@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

As to the patch, would you please elaborate on your changes more? To me, it is simply inlining `Key.normalize(key)` content into `Cache.createObject()`, and not sure how it prevents the issue in which the referent got GC'ed during the reference creation and use.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1572826469

From duke at openjdk.org  Fri Jun  2 01:10:11 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 2 Jun 2023 01:10:11 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

> 367:             BaseLocale l = key.holder;
> 368:             BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
> 369:             return (new Key(locale)).getBaseLocale();

Perhaps a more rigorous approach would look like this?
<pre><code class="java">
BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
BaseLocal value = (new Key(locale)).getBaseLocale();
Reference.reachabilityFence(locale);
return value;
</code></pre>
But the current patch has passed the tests with `-XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, so I think the current patch is OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1213813143

From duke at openjdk.org  Fri Jun  2 01:30:06 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 2 Jun 2023 01:30:06 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <VW0d0G5A5DXLwKTartQijiUdmG2H19-q_PY_iB55DeE=.23d70c40-6a5a-40d2-b060-9dee7fbffe75@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VW0d0G5A5DXLwKTartQijiUdmG2H19-q_PY_iB55DeE=.23d70c40-6a5a-40d2-b060-9dee7fbffe75@github.com>
Message-ID: <Q2qtCrM5PZ2kCxTzIKA69ApFFqheiY4lZbGvgfCTX9M=.0973512a-bc8f-4959-b307-362843c60252@github.com>

On Thu, 1 Jun 2023 09:03:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared
>
> I've done basic testing jtreg tier1-3 and partial shenandoah testing with vmoptions `-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, the results are all OK.

>  @sunny868 Would you be able to add a JMH test to make sure that your change would not affect the startup time? 

All JMH tests or some of them? I had trigger JMH test, waiting for run results.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1572999255

From duke at openjdk.org  Fri Jun  2 02:10:09 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 2 Jun 2023 02:10:09 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <kFeOAbID5CsptDtVeKZ-O2RhUD50AUEB10vP0p8i4UM=.0e3ef102-e406-44a7-9698-0eaf5bd38a15@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

`make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot" TEST=java/util/Locale/SoftKeys.java` can trigger  same error:
<pre><code class="shell">
Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
	at java.base/java.util.Locale.forLanguageTag(Locale.java:1876)
	at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:45)
	... 19 more
</code></pre>
this patch can fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1573032287

From duke at openjdk.org  Mon Jun  5 09:39:10 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 5 Jun 2023 09:39:10 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <mmnDcX31n-xxwpFb14LwXHdY6mNeeNgw0Vx2dUiP51M=.e50709d0-0aeb-4b13-aea6-5752dbb7b530@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

Existing JMH Local test results be tested on LOONGARCH64 show no performance fallback.
<pre><code class="shell">
// parent
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    3  35.731 ? 0.805  ns/op
LocaleDefaults.getDefaultDisplay  avgt    3  36.099 ? 1.037  ns/op
LocaleDefaults.getDefaultFormat   avgt    3  36.123 ? 1.718  ns/op

// current
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    3  35.649 ? 0.264  ns/op
LocaleDefaults.getDefaultDisplay  avgt    3  36.141 ? 1.283  ns/op
LocaleDefaults.getDefaultFormat   avgt    3  36.092 ? 1.371  ns/op

</code></pre>

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1576462477

From naoto at openjdk.org  Mon Jun  5 21:50:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Jun 2023 21:50:56 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
Message-ID: <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>

On Fri, 2 Jun 2023 01:07:27 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> SUN Guoyun has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 369:
> 
>> 367:             BaseLocale l = key.holder;
>> 368:             BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
>> 369:             return (new Key(locale)).getBaseLocale();
> 
> Perhaps a more rigorous approach would look like this?
> <pre><code class="java">
> BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
> BaseLocal value = (new Key(locale)).getBaseLocale();
> Reference.reachabilityFence(locale);
> return value;
> </code></pre>
> But the current patch has passed the tests with `-XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, so I think the current patch is OK.

I still don't see a clear explanation of how the proposed patch fixes the problem. Also, I would appreciate the reasoning in the comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1218629550

From duke at openjdk.org  Tue Jun  6 02:33:52 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 6 Jun 2023 02:33:52 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
Message-ID: <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>

On Mon, 5 Jun 2023 21:48:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 369:
>> 
>>> 367:             BaseLocale l = key.holder;
>>> 368:             BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
>>> 369:             return (new Key(locale)).getBaseLocale();
>> 
>> Perhaps a more rigorous approach would look like this?
>> <pre><code class="java">
>> BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
>> BaseLocal value = (new Key(locale)).getBaseLocale();
>> Reference.reachabilityFence(locale);
>> return value;
>> </code></pre>
>> But the current patch has passed the tests with `-XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, so I think the current patch is OK.
>
> I still don't see a clear explanation of how the proposed patch fixes the problem. Also, I would appreciate the reasoning in the comments.

For hotspot, when GC occurs, it causes all threads to run to the nearest safepoint and then freeze. Generally, safepoints are generated at branch jumps, method ends(ret instructions), loops instructions, and so on. Therefore, the purpose of this patch is to make the creation and use of a softReferences in the same method without branch, jumps and loops in between, that is ensure that GC will not occur in the process of the sofeReferences be created and used.

That's why I didn't use `Reference.reachabilityFence(locale)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1218793510

From duke at openjdk.org  Tue Jun  6 03:03:30 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 6 Jun 2023 03:03:30 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v4]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <D8om79XyCpwmSnuz9P0j412JAe4DuvPqu9nz03EdXdU=.f10c4b1b-1d94-482d-9944-660651b63b9b@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/a09f1b6f..75fd5951

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

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

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

From duke at openjdk.org  Tue Jun  6 09:30:08 2023
From: duke at openjdk.org (duke)
Date: Tue, 6 Jun 2023 09:30:08 GMT
Subject: <i18n dev> Withdrawn: JDK-8303950: [macos]Translucent Windows
 Flicker on Repaint
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <esUDEGSeTgTtGyidBOzgqkRZc3DIB0Yt0UqscIBynCI=.eb4b44e7-1fc0-4e78-9db3-f3cb02f1abdf@github.com>

On Sun, 12 Mar 2023 17:35:40 GMT, Jeremy <duke at openjdk.org> wrote:

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

This pull request has been closed without being integrated.

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

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

From eosterlund at openjdk.org  Tue Jun  6 18:50:59 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 6 Jun 2023 18:50:59 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
 <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
Message-ID: <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>

On Tue, 6 Jun 2023 02:31:19 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> I still don't see a clear explanation of how the proposed patch fixes the problem. Also, I would appreciate the reasoning in the comments.
>
> For hotspot, when GC occurs, it causes all threads to run to the nearest safepoint and then freeze. Generally, safepoints are generated at branch jumps, method ends(ret instructions), loops instructions, and so on. Therefore, the purpose of this patch is to make the creation and use of a softReferences in the same method without branch, jumps and loops in between, that is ensure that GC will not occur in the process of the sofeReferences be created and used.
> 
> That's why I didn't use `Reference.reachabilityFence(locale)`.

This reasoning seems invalid. There are method calls in there, and you rely on inlining heuristics for this not to break. Please use reachabilityFence instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1220145376

From jrose at openjdk.org  Tue Jun  6 18:51:00 2023
From: jrose at openjdk.org (John R Rose)
Date: Tue, 6 Jun 2023 18:51:00 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
 <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
 <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
Message-ID: <cg-mJd32zg9bo8hVUMYAzXynunyy5MwGXkAfcMPACa0=.0879793a-078f-44c6-a279-bbec432802a8@github.com>

On Tue, 6 Jun 2023 18:45:50 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> For hotspot, when GC occurs, it causes all threads to run to the nearest safepoint and then freeze. Generally, safepoints are generated at branch jumps, method ends(ret instructions), loops instructions, and so on. Therefore, the purpose of this patch is to make the creation and use of a softReferences in the same method without branch, jumps and loops in between, that is ensure that GC will not occur in the process of the sofeReferences be created and used.
>> 
>> That's why I didn't use `Reference.reachabilityFence(locale)`.
>
> This reasoning seems invalid. There are method calls in there, and you rely on inlining heuristics for this not to break. Please use reachabilityFence instead.

It appears you are assuming that some combination of bytecodes constitutes a  critical section that excludes the GC.  But the JVMS makes no guarantees about GC exclusion across bytecodes.

A thread can be pre-empted at any bytecode (even in the middle of a bytecode).  Another thread can trigger a GC.  Maybe the first thread will be rolled forward to a place convenient to the JVM, but you cannot predict what that will be, because the JVMS does not give you any contract about that matter.

For example, some JITs deoptimize (branch to the interpreter) at unpredictable points for reasons no Java programmer should ever think about (because it?s not in the JVMS contract).  Deoptimizing can allocate storage (for example, to materialize objects whose allocation was deferred by escape analysis).  Thus, it is not safe to assume that any particular bytecode is immune from GC.

Also, some JITs (like C2) inject synthetic safepoints injected as part of arbitrarily complex loop transformations.  A GC at such a safepoint might possibly appear to be tied to a bytecode which is simply a fall-through from a previous bytecode.  This can happen if the loop is rotated, and a fallthrough point begins to function as a back-branch in the IR.

The rule of thumb for non-JIT engineers is, if you find yourself trying to predict what how ?the JIT must work?, stop.

The net of this is that, if you need to preserve an object across a critical section, don?t try to read the JIT?s mind or expect it to read yours.  Put in a reachability fence that spans that critical section.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1220148743

From duke at openjdk.org  Wed Jun  7 01:53:04 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 7 Jun 2023 01:53:04 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v5]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <U1taCulwNbXWrtBOl0e0_vg6FRoBpVjf3j8-2oKx4nU=.161fee89-1551-4849-8f0b-e79c4e6364e2@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/75fd5951..d133a15c

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

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

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

From smarks at openjdk.org  Wed Jun  7 01:53:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 7 Jun 2023 01:53:05 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <cg-mJd32zg9bo8hVUMYAzXynunyy5MwGXkAfcMPACa0=.0879793a-078f-44c6-a279-bbec432802a8@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
 <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
 <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
 <cg-mJd32zg9bo8hVUMYAzXynunyy5MwGXkAfcMPACa0=.0879793a-078f-44c6-a279-bbec432802a8@github.com>
Message-ID: <0SrlLvQQ8ZSU8I8y89VnPDy_DbLtS-_iqYDfiO2yoSM=.06cf5806-221b-47f1-b4f3-4a44655d5e2a@github.com>

On Tue, 6 Jun 2023 18:48:35 GMT, John R Rose <jrose at openjdk.org> wrote:

>> This reasoning seems invalid. There are method calls in there, and you rely on inlining heuristics for this not to break. Please use reachabilityFence instead.
>
> It appears you are assuming that some combination of bytecodes constitutes a  critical section that excludes the GC.  But the JVMS makes no guarantees about GC exclusion across bytecodes.
> 
> A thread can be pre-empted at any bytecode (even in the middle of a bytecode).  Another thread can trigger a GC.  Maybe the first thread will be rolled forward to a place convenient to the JVM, but you cannot predict what that will be, because the JVMS does not give you any contract about that matter.
> 
> For example, some JITs deoptimize (branch to the interpreter) at unpredictable points for reasons no Java programmer should ever think about (because it?s not in the JVMS contract).  Deoptimizing can allocate storage (for example, to materialize objects whose allocation was deferred by escape analysis).  Thus, it is not safe to assume that any particular bytecode is immune from GC.
> 
> Also, some JITs (like C2) inject synthetic safepoints injected as part of arbitrarily complex loop transformations.  A GC at such a safepoint might possibly appear to be tied to a bytecode which is simply a fall-through from a previous bytecode.  This can happen if the loop is rotated, and a fallthrough point begins to function as a back-branch in the IR.
> 
> The rule of thumb for non-JIT engineers is, if you find yourself trying to predict what how ?the JIT must work?, stop.
> 
> The net of this is that, if you need to preserve an object across a critical section, don?t try to read the JIT?s mind or expect it to read yours.  Put in a reachability fence that spans that critical section.

I don't know what the right fix for this is. If it involves reachabilityFence, then a try-finally statement should be used, with the "critical section" being within the try-clause and the reachabilityFence within the finally-clause.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1220682487

From duke at openjdk.org  Wed Jun  7 03:37:26 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 7 Jun 2023 03:37:26 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v6]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:

  8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/d133a15c..98a8bd62

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

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

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

From duke at openjdk.org  Wed Jun  7 03:37:26 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 7 Jun 2023 03:37:26 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v3]
In-Reply-To: <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
 <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
 <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
Message-ID: <tCCaUOJwokQQ4n3V4fPyowPLOgjk5crMtUNwZtex9nY=.4c067d45-f14b-4b34-a96f-3d15cc63f223@github.com>

On Tue, 6 Jun 2023 18:45:50 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> For hotspot, when GC occurs, it causes all threads to run to the nearest safepoint and then freeze. Generally, safepoints are generated at branch jumps, method ends(ret instructions), loops instructions, and so on. Therefore, the purpose of this patch is to make the creation and use of a softReferences in the same method without branch, jumps and loops in between, that is ensure that GC will not occur in the process of the sofeReferences be created and used.
>> 
>> That's why I didn't use `Reference.reachabilityFence(locale)`.
>
> This reasoning seems invalid. There are method calls in there, and you rely on inlining heuristics for this not to break. Please use reachabilityFence instead.

Thanks @fisk @rose00 for the explanation. This patch is indeed based on the idea that small functions are inlined, cause `-Xcomp` be used, and I have seen with parameter `-XX:+PrintCompilation -XX:+PrintInlining` that functions `Key::<init>` and `getBaseLocale` are inlined. 
But as @rose00  say, it's not safe, so reachabilityFence should be used. please review again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1220780841

From aturbanov at openjdk.org  Wed Jun  7 08:55:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 7 Jun 2023 08:55:57 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v6]
In-Reply-To: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
Message-ID: <IG5otj0aETda_DVB45ZU8sB_L8z24F6oSsA_Jhx_VVo=.44cdcd78-c769-4b0f-af6d-5b4a2c5b7aea@github.com>

On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

> 369:             BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
> 370:             try {
> 371:                 BaseLocale value = (new Key(locale)).getBaseLocale();

I don't understand. Why do we need to create thrown-away `new Key` here?
Can we just use locale?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1221187752

From djelinski at openjdk.org  Wed Jun  7 11:59:57 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jun 2023 11:59:57 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v6]
In-Reply-To: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
Message-ID: <wxh0x-vY5XEoXaoWGDLZ30xC_1Wp9LJogCKeCOMfIwQ=.38291318-759a-4746-b7c7-8a09265a8c5d@github.com>

On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

In its current form the `BaseLocale.Cache.createObject` function can return `null`; the object returned by `BaseLocale.Key.normalizeKey(key)` holds a soft reference to locale, and by the time `getBaseLocale` is called, the reference may be cleared.

`Key` only uses `SoftReferences` because it must not hold a reference to the object returned by `createObject`. We could refactor `createObject` to return a clone of the `BaseLocale` referenced by `Key`, and then `Key` would not need to use `SoftReference`s.

That being said, the number of long-lived `BaseLocale` objects is very limited; we only keep them in Locale, LocaleKey, and Locale.CONSTANT_LOCALES. Unless I'm missing something, we could solve this problem by removing `BaseLocale` caching, and improve performance at the same time.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1580652895

From alanb at openjdk.org  Wed Jun  7 12:46:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 12:46:07 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v6]
In-Reply-To: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
Message-ID: <fM7TFfAz0PmVC43LpifuiiTUbyrZYXWxtNSuYZwuI_E=.508e494b-8b30-4953-b5e8-154388a7ae6b@github.com>

On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

src/java.base/share/classes/sun/util/locale/LocaleObjectCache.java line 63:

> 61:             if (newVal == null) {
> 62:                 // subclass must return non-null key/value object
> 63:                 throw new NullPointerException();

Is this caught somewhere, it seem strange to throw NPE here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1221526553

From alanb at openjdk.org  Wed Jun  7 12:51:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 12:51:01 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v6]
In-Reply-To: <wxh0x-vY5XEoXaoWGDLZ30xC_1Wp9LJogCKeCOMfIwQ=.38291318-759a-4746-b7c7-8a09265a8c5d@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
 <wxh0x-vY5XEoXaoWGDLZ30xC_1Wp9LJogCKeCOMfIwQ=.38291318-759a-4746-b7c7-8a09265a8c5d@github.com>
Message-ID: <e9KmF_NHL2J4e_a8T8N0KrVNctXCdnJRcS9HNw7o0JM=.42119706-8f71-4d51-a624-88e161dd58d9@github.com>

On Wed, 7 Jun 2023 11:55:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> That being said, the number of long-lived `BaseLocale` objects is very limited; we only keep them in Locale, LocaleKey, and Locale.CONSTANT_LOCALES. Unless I'm missing something, we could solve this problem by removing `BaseLocale` caching, and improve performance at the same time.

The motivation seems to be startup ([JDK-8196869](https://bugs.openjdk.org/browse/JDK-8196869)). It looks like it needs to be re-evaluated and if we continue with caching in this area then I think we'll need some stress tests to go with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1580746429

From naoto at openjdk.org  Wed Jun  7 16:25:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Jun 2023 16:25:57 GMT
Subject: <i18n dev> RFR: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared [v6]
In-Reply-To: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
Message-ID: <BI0NLGYtNhME9B5RqakCgqtewbY4oQY2lpBdbErw-u4=.1cb6ebe6-5ea3-4b01-98f7-706823d47696@github.com>

On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

Good point Daniel. I created an issue for re-examining the cache mechanism in `BaseLocale`: https://bugs.openjdk.org/browse/JDK-8309622

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1581155416

From naoto at openjdk.org  Fri Jun  9 23:34:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Jun 2023 23:34:44 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
Message-ID: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>

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

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

Commit messages:
 - minor comment fix
 - equals/hash fix, constructor simplification
 - Removed Key
 - minor fixup
 - Use WeakHashMap
 - Modified JMH test
 - Added a test variation for the issue
 - added microbenchmark
 - 8309622: Re-examine the cache mechanism in BaseLocale

Changes: https://git.openjdk.org/jdk/pull/14404/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309622
  Stats: 244 lines in 3 files changed: 104 ins; 117 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

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

From ayang at openjdk.org  Mon Jun 12 12:51:52 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Jun 2023 12:51:52 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>

On Fri, 9 Jun 2023 22:17:39 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

test/hotspot/jtreg/gc/TestAllocHumongousFragment.java line 180:

> 178:  */
> 179: 
> 180: /*

Could you move this block a few lines above (e.g. next to the block of `id=iu-aggressive`) so that similar tests are grouped together?

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

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

From dfuchs at openjdk.org  Mon Jun 12 14:29:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:29:50 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>

On Fri, 9 Jun 2023 22:17:39 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

The new code looks much easier to maintain than the old one. I couldn't figure out what the old code was actually trying to do, but reading the new code I now understand what it does. Caching, retrieval, hashCode and equals look good. From the code it's trivial to see that a new normalised BaseLocale will be created if none is found in the cache - so that will assuredly fix the NPE that was experienced previously when the cache was cleared. The main change is that base locales will now be cached using WeakReference rather than SoftReference, and thus probably collected more eagerly, but that actually looks like a positive change. Not a usual reviewer in this area so please get another reviewer before integrating (also I haven't looked at the test).

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475076367

From dfuchs at openjdk.org  Mon Jun 12 14:37:41 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:37:41 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>

On Fri, 9 Jun 2023 22:17:39 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

One thing though - WeakHashMap is not thread safe - and I don't see any locks or synchronized to protect access to CACHE. Is that going to cause trouble if two threads compete to add a locale to the map? In other words - how confident are we that the race would be benign?

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

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475096535

From dfuchs at openjdk.org  Mon Jun 12 14:40:43 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:40:43 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <nw4cq4eBoIjvhodXS-V3HULh5PrdMx6EaG31daNumdw=.05dc657b-3a90-4394-85cd-fff2445d2fb8@github.com>

On Fri, 9 Jun 2023 22:17:39 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

I think this question should be answered before integrating.

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475101795

From pminborg at openjdk.org  Mon Jun 12 14:41:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Jun 2023 14:41:22 GMT
Subject: <i18n dev> RFR: 8295555: Primitive wrapper caches could be `@Stable`
Message-ID: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>

This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).

Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

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

Commit messages:
 - Fix trailing white spaces
 - Reinsert row
 - Annotate CharacterCache @Stable
 - Mark caching arrays @Stable

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

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

From pminborg at openjdk.org  Mon Jun 12 14:41:23 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Jun 2023 14:41:23 GMT
Subject: <i18n dev> RFR: 8295555: Primitive wrapper caches could be
 `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <UTzoXtmaBegvSw8rem61WqS-aywYHUIq9U6rNN9Qua4=.e6a4e9be-0234-412c-88df-cce16e10ab8c@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

The performance is similar with this PR compared to the base line:

Before:

Benchmark         (size)  Mode  Cnt  Score   Error  Units
Integers.valueOf     500  avgt   15  0.652 ? 0.003  ns/op


After

Benchmark         (size)  Mode  Cnt  Score   Error  Units
Integers.valueOf     500  avgt   15  0.649 ? 0.003  ns/op



    @State(Scope.Thread)
    public static class Data {
       int value = 42;
    }
    
    ...
    
    @Benchmark
    public void valueOf(Data data, Blackhole bh) {
        bh.consume(Integer.valueOf(data.value));
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/14418#issuecomment-1587463431

From dfuchs at openjdk.org  Mon Jun 12 14:47:49 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:47:49 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>
Message-ID: <IIbDWS7D9Utzs38_5cnY4pjte1NvtI-u9LJ1bFLnrTY=.0d5f3a99-546c-4bc7-a219-f6db77493b79@github.com>

On Mon, 12 Jun 2023 14:26:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The main change is that base locales will now be cached using WeakReference rather than SoftReference, and thus probably collected more eagerly, but that actually looks like a positive change.

Hmm.... or not. Nothing references the key, so the binding would be immediately eligible for garbage collection.

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587493993

From liach at openjdk.org  Mon Jun 12 14:54:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 14:54:51 GMT
Subject: <i18n dev> RFR: 8295555: Primitive wrapper caches could be
 `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <TGxcnUj9RbMmCL2ZbnoOy5O5_BqVHK_0lch3qKNFIdw=.9998ac2d-7d2d-4cb5-9030-969fa8764c68@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

Seems the `valueOf` APIs already have `@IntrinsicCandidate` and might have some custom logic in C2 or other jit compilers, so there's no performance difference.

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

PR Comment: https://git.openjdk.org/jdk/pull/14418#issuecomment-1587505610

From rriggs at openjdk.org  Mon Jun 12 16:02:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Jun 2023 16:02:41 GMT
Subject: <i18n dev> RFR: 8295555: Primitive wrapper caches could be
 `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <S64hov6EWfwmY4ICCmdkXMEKwHgpt_v5k4uWsEvMaQQ=.677da9cc-2d6c-4c3c-904c-fed3d7305dcf@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

Looks good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14418#pullrequestreview-1475272046

From rriggs at openjdk.org  Mon Jun 12 16:26:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Jun 2023 16:26:43 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>

On Fri, 9 Jun 2023 22:17:39 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

One other thing to consider...
If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced.
Eliminating `.intern90` would make creating a normalized BaseLocale faster.

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587662100

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>

> 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 incrementally with one additional commit since the last revision:

  Addressing comments (test grouping, synchronization), minor optimization on loop lookup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/06d199dc..fb1535ff

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

  Stats: 55 lines in 2 files changed: 16 ins; 14 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

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

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>
Message-ID: <g2oOmzsd58gopPKyf3NS12-XXfcX9naws8Q6_1dNj7Q=.2ded240e-49bb-4b2b-a38e-11108db25cdb@github.com>

On Mon, 12 Jun 2023 14:35:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> One thing though - WeakHashMap is not thread safe - and I don't see any locks or synchronized to protect access to CACHE. Is that going to cause trouble if two threads compete to add a locale to the map? In other words - how confident are we that the race would be benign?

Although I think the possible race is benign (it would simply overwrite the existing normalized one), I put it in a synchronization block as a safety measure, as the race would be quite rare for creating a BaseLocale instance. Tested with the microbench mark and I didn't see the number change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587759179

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>
Message-ID: <pw8M2rDyrS5DSt4Hxk7poIQ5pL6c9ZJKuL49-6DaWOQ=.e11e348f-7beb-4c1a-ab03-56e819893530@github.com>

On Mon, 12 Jun 2023 16:23:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> One other thing to consider... If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced. Eliminating `.intern90` would make creating a normalized BaseLocale faster.

Some code inside the Locale still relies on `intern` and do `==` comparison. Yes, it would be faster but I think that would be out of the scope of this fix

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587760602

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>
Message-ID: <7znWt-HGeAbK4ngG1xgIas71tNbe3yUHhPCz5sR42_Y=.24d27c62-2d80-4b70-b0b9-3d178902fed1@github.com>

On Mon, 12 Jun 2023 12:49:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> test/hotspot/jtreg/gc/TestAllocHumongousFragment.java line 180:
> 
>> 178:  */
>> 179: 
>> 180: /*
> 
> Could you move this block a few lines above (e.g. next to the block of `id=iu-aggressive`) so that similar tests are grouped together?

Moved the block next to `iu-aggressive`

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

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

From dfuchs at openjdk.org  Mon Jun 12 19:03:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 19:03:44 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <Jvmfztugmp9z0ePb3HyHZw8n4I2xnfFZK1A2JxOpEWY=.1b9b1ab5-643c-4a91-a67b-9d0b9f93f776@github.com>

On Mon, 12 Jun 2023 17:33:11 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 incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

LGTM

FWIW I am not sure the race would have been benign - as `put` is not atomic - so I wouldn't be surprised if concurrent `put`s  could have resulted in an inconsistent internal state for the `WeakHashMap`.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475620449

From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

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

Commit messages:
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk21/pull/11/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

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

From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <-g_p5DXIJa2iFx-wYX9Fl024cy_wOxNlIN3g8TB5V1E=.84d95609-9341-4a50-afa2-e9dcb462a0bb@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588123540

From jlu at openjdk.org  Mon Jun 12 21:29:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:29:54 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588130775

From kcr at openjdk.org  Mon Jun 12 21:45:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Jun 2023 21:45:55 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
Message-ID: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>

On Mon, 12 Jun 2023 21:27:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

@justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.

See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588146416

From jlu at openjdk.org  Mon Jun 12 21:55:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:55:48 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
 <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
Message-ID: <ZVzi-lqSlf4r01XSuWXwqs8_Ku3uEGgB_f2BRDOqsvQ=.9c38d799-5e1e-4ec7-8f74-81a9603cde4d@github.com>

On Mon, 12 Jun 2023 21:42:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.
>
> @justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.
> 
> See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

@kevinrushforth Thanks for the reminder, will make the change in ML first.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588156115

From jlu at openjdk.org  Mon Jun 12 22:07:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:07:11 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

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

Commit messages:
 - Merge remote-tracking branch 'justinJDK21/JDK21-RDP1-L10nDrop' into JDK21-L10NDrop-RDP1
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk/pull/14430/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

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

From jlu at openjdk.org  Mon Jun 12 22:16:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:16:50 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <sLPcMLisa0Fflyr2kNxtrP3t6X2r7TFh7K59biOLnuw=.cb69b335-cac4-4565-9587-93d4abfae7ed@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1588180092

From duke at openjdk.org  Mon Jun 12 22:20:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 12 Jun 2023 22:20:53 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227296089

From jlu at openjdk.org  Mon Jun 12 22:32:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:14 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

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

  Revert 'main.help.opt.any.file' value for _de

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/ee072231..8ee7bf88

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

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

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

From jlu at openjdk.org  Mon Jun 12 22:32:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:34 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
Message-ID: <QG0atcb6MH7fn3CaUG7kFAU8Z-0dx0lvt8vPPzz6fD4=.750f4a45-f895-49f6-becd-7d9e6c994207@github.com>

On Mon, 12 Jun 2023 22:17:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:
> 
>> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
>> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
>> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)
> 
> This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

Thanks for catching that. The translation tool incorrectly translated this, and we had manually fixed it with `Auslassen` in the last translation drop. This was an instance of the tool simply overwriting it this time. Will file a bug against the translation tool regarding this, to prevent it in future translation drops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227305807

From pminborg at openjdk.org  Tue Jun 13 08:41:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Jun 2023 08:41:59 GMT
Subject: <i18n dev> RFR: 8295555: Primitive wrapper caches could be
 `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <cZJ4__D8IQz4CKNvwoFbMrSJbBBU7BxzsecnBLvDQIE=.c075b620-040b-41dd-bfa5-df704645c71c@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

The benchmarks I provided above does not involve constant folding so here is another set of benchmarks (Thanks @cl4es):

Before

Benchmark                     (size)  Mode  Cnt  Score   Error  Units
Integers.constantFoldInteger     500  avgt   15  0.568 ? 0.013  ns/op
Integers.constantFoldInts        500  avgt   15  0.564 ? 0.005  ns/op


After

Benchmark                     (size)  Mode  Cnt  Score   Error  Units
Integers.constantFoldInteger     500  avgt   15  0.558 ? 0.001  ns/op
Integers.constantFoldInts        500  avgt   15  0.559 ? 0.001  ns/op



    @Benchmark
    public int constantFoldInteger() {
        return Integer.valueOf(64) * Integer.valueOf(32);
    }

    @Benchmark
    public int constantFoldInts() {
        return 64 * 32;
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/14418#issuecomment-1588823240

From pminborg at openjdk.org  Tue Jun 13 08:42:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Jun 2023 08:42:00 GMT
Subject: <i18n dev> Integrated: 8295555: Primitive wrapper caches could be
 `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <2i2i_LDCzog0M62mIuQ8QTZKBu4tkd8uXJLI68b5Rqs=.ba13193a-49c7-49fa-9b1d-f14797776b68@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

This pull request has now been integrated.

Changeset: f7de726b
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7de726bd37a2f1fa6f63b601cd2dab1805234e8
Stats:     16 lines in 5 files changed: 11 ins; 0 del; 5 mod

8295555: Primitive wrapper caches could be `@Stable`

Reviewed-by: rriggs

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

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

From alanb at openjdk.org  Tue Jun 13 11:24:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Jun 2023 11:24:52 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>

On Mon, 12 Jun 2023 17:33:11 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 incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

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

> 164:         // can subsequently be used by the Locale instance which
> 165:         // guarantees the locale components are properly cased/interned.
> 166:         synchronized (BaseLocale.class) {

The simplification is good but I wonder if this coarse locking is going to be a problem, do we need to use some concurrent to avoid contention here?

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

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

From aturbanov at openjdk.org  Tue Jun 13 13:14:54 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 Jun 2023 13:14:54 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>

On Mon, 12 Jun 2023 17:33:11 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 incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

test/micro/org/openjdk/bench/java/util/LocaleCache.java line 58:

> 56:                 throw new RuntimeException("Different Locale was created");
> 57:             }
> 58:             previous =  l;

Suggestion:

            previous = l;

test/micro/org/openjdk/bench/java/util/LocaleCache.java line 70:

> 68:                 throw new RuntimeException("Different Locale was created");
> 69:             }
> 70:             previous =  l;

Suggestion:

            previous = l;

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

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

From naoto at openjdk.org  Tue Jun 13 17:56:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 17:56:57 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v3]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>

> 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 incrementally with one additional commit since the last revision:

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/fb1535ff..ac6ea421

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

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

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

From naoto at openjdk.org  Tue Jun 13 18:00:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:00:53 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
Message-ID: <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>

On Tue, 13 Jun 2023 11:22:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 166:
> 
>> 164:         // can subsequently be used by the Locale instance which
>> 165:         // guarantees the locale components are properly cased/interned.
>> 166:         synchronized (BaseLocale.class) {
> 
> The simplification is good but I wonder if this coarse locking is going to be a problem, do we need to use some concurrent to avoid contention here?

Replaced it with a ReentrantLock

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

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

From naoto at openjdk.org  Tue Jun 13 18:00:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:00:57 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>
Message-ID: <FgaAVqdLpB3Raw_J5LTFCFKjrapHhgOuR6_LoDcFx94=.c7246736-c8cb-4959-9830-3b071ebef54a@github.com>

On Tue, 13 Jun 2023 13:09:49 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> test/micro/org/openjdk/bench/java/util/LocaleCache.java line 58:
> 
>> 56:                 throw new RuntimeException("Different Locale was created");
>> 57:             }
>> 58:             previous =  l;
> 
> Suggestion:
> 
>             previous = l;

Fixed

> test/micro/org/openjdk/bench/java/util/LocaleCache.java line 70:
> 
>> 68:                 throw new RuntimeException("Different Locale was created");
>> 69:             }
>> 70:             previous =  l;
> 
> Suggestion:
> 
>             previous = l;

Fixed

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

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

From naoto at openjdk.org  Tue Jun 13 18:41:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:41:52 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

The translation seems wrong. It means to *add* the selected file, which is not the same meaning as in English file

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:

> 138: 
> 139: # 0: type, 1: name
> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf

Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 505:

> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059
> 505: 

These translations are very cryptic. Cannot understand it at first hand.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:

> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 959: 

The translation of "well-formed" is incorrect. It is not ???

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

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477795175
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228530280
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228521409
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228538758
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228529769

From jlu at openjdk.org  Tue Jun 13 18:56:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 18:56:44 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>

On Tue, 13 Jun 2023 18:13:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
> 
>> 138: 
>> 139: # 0: type, 1: name
>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
> 
> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let ask about this specific instance.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:
> 
>> 957: 
>> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
>> 959: 
> 
> The translation of "well-formed" is incorrect. It is not ???

For translations that are incorrect, I can file a bug against the tool. Such a fix would probably not happen soon, can you suggest an alternative for now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228567669
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228570665

From naoto at openjdk.org  Tue Jun 13 20:24:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 20:24:46 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some suggestions. Should be looked at by translators later.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

Suggestion:

FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 502:

> 500: compiler.warn.forward.ref=\u521D\u671F\u5316\u3055\u308C\u308B\u524D\u306E\u5909\u6570''{0}''\u3092\u53C2\u7167\u3057\u3088\u3046\u3068\u3057\u307E\u3057\u305F
> 501: 
> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape=\u30b5\u30d6\u30af\u30e9\u30b9\u304c\u521d\u671f\u5316\u3055\u308c\u308b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306e\u53ef\u80fd\u6027\u304c\u3042\u308a\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 504:

> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059
> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape.location=\u4e8b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306f\u3053\u306e\u547c\u3073\u51fa\u3057\u3067\u51fa\u73fe\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 956:

> 954: compiler.err.unclosed.text.block=\u9589\u3058\u3089\u308C\u3066\u3044\u306A\u3044\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF
> 955: 
> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.string.template.is.not.well.formed=\u6587\u5b57\u5217\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 958:

> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.text.block.template.is.not.well.formed=\u30c6\u30ad\u30b9\u30c8\u30fb\u30d6\u30ed\u30c3\u30af\u30fb\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

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

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477963618
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228635514
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228648714
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228651272
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228653057
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228654384

From weijun at openjdk.org  Tue Jun 13 20:58:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jun 2023 20:58:51 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Some comments:

- `src/java.base/share/classes/sun/launcher/resources/launcher`

`? private`. "private" should be translated, just like the "static" in the 2nd box.

- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`

`compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?

`compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.

`compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".


- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:

`javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.

- `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`

I don't think the new translation is better than the old one.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590013825

From jlu at openjdk.org  Tue Jun 13 21:06:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:25 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v3]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <geYM5H0XN5NNvVmRzx5TxgqMaD17xbb7-DCnO_oFVbw=.d00caade-f19d-466e-a71d-7f7cbba183cc@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

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

  Review: use Naoto's recommended ja values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/8ee7bf88..7801eefb

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

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

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

From jlu at openjdk.org  Tue Jun 13 21:06:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:28 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
Message-ID: <Kj4eUHsEVJoYJLTG7eTiBVFd68yRljmoagn0pAEqPdI=.0c0cf9b7-9710-4802-9cce-aad8c0f35a71@github.com>

On Tue, 13 Jun 2023 19:59:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:
> 
>> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
>> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
>> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059
> 
> Suggestion:
> 
> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

Thank you Naoto, all your recommended translations have been updated. The HTML diffs have also been updated as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228692234

From jlu at openjdk.org  Tue Jun 13 22:09:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:40 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v4]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

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

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/7801eefb..f7c06512

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

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

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

From jlu at openjdk.org  Tue Jun 13 22:09:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:43 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
Message-ID: <eUpEuDxtBW4zFIazvfci4moBpPFzPDXyAkpgYNd4F9E=.61170e21-43a3-40d7-a5cc-fc9685a8a2e2@github.com>

On Tue, 13 Jun 2023 20:56:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> Some comments:
> 
> - `src/java.base/share/classes/sun/launcher/resources/launcher`
> 
> `? private`. "private" should be translated, just like the "static" in the 2nd box.
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`
> 
> `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?
> 
> `compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.
> 
> `compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".
> 
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
> - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> I don't think the new translation is better than the old one.

Thank you for the review @wangweij,

I have addressed these recommendations

>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
>     * `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> 
> I don't think the new translation is better than the old one.

For the other comments, I will bring them to the language specialist for updated translations. Ideally we can get those in for this translation drop, but if not, they can go in during the second translation drop during RDP2. 

I am also hesitant to make too many manual changes, as they will just get overwritten by the tool in the future, so it's best to get it fixed in the tool first.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590087839

From naoto at openjdk.org  Wed Jun 14 00:09:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 00:09:03 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v4]
In-Reply-To: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
Message-ID: <sGkMLbM6Iyp04SnzPdG_CLR9wMlzypOQwrpdy_9iheM=.1f136a3d-f264-42a2-85e5-c4506564eb74@github.com>

On Tue, 13 Jun 2023 22:09:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value

Looks good, Justin

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1478236336

From alanb at openjdk.org  Wed Jun 14 13:17:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 13:17:04 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
Message-ID: <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>

On Tue, 13 Jun 2023 17:57:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Replaced it with a ReentrantLock

The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.

On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.

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

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

From dfuchs at openjdk.org  Wed Jun 14 13:34:59 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 14 Jun 2023 13:34:59 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
 <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
Message-ID: <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>

On Wed, 14 Jun 2023 13:13:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Replaced it with a ReentrantLock
>
>> Replaced it with a ReentrantLock
> 
> The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.
> 
> On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.

One possibility would be to have the whole cache be soft-referenced, instead of individually weak-referencing the keys.
Something like Reference<Map<BaseLocale, BaseLocale>> where Reference is a SoftReference and Map is a ConcurrentHashMap. 
But then you'd have to deal with a non-final field for the reference to the cache, and creating a new map and a new cache (and new SoftReference) when the reference to the cache gets cleared, and dealing with potential race conditions at that time.

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

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

From naoto at openjdk.org  Wed Jun 14 16:07:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 16:07:59 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v2]
In-Reply-To: <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
 <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
 <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>
Message-ID: <95kv6OUnZpcUEpnvAyZZYgeA7JTMmuau8NMBlb62u0Y=.a47b5d21-669c-4633-93f9-eaaf27657109@github.com>

On Wed, 14 Jun 2023 13:29:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Replaced it with a ReentrantLock
>> 
>> The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.
>> 
>> On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.
>
> One possibility would be to have the whole cache be soft-referenced, instead of individually weak-referencing the keys.
> Something like Reference<Map<BaseLocale, BaseLocale>> where Reference is a SoftReference and Map is a ConcurrentHashMap. 
> But then you'd have to deal with a non-final field for the reference to the cache, and creating a new map and a new cache (and new SoftReference) when the reference to the cache gets cleared, and dealing with potential race conditions at that time.

Jim's `java.lang.runtime.ReferenceKeyMap` would be a possible solution for it, although it is currently package private. But I will need to think about it more as Alan suggests.

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

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

From jlu at openjdk.org  Wed Jun 14 16:25:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 Jun 2023 16:25:00 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
Message-ID: <i2xpAM4Cbkg3wxLwU6xXUsAerpA3w3n1wHE9BFFtI0Q=.49a5cd2b-b201-4322-af3a-dd198470a544@github.com>

On Tue, 13 Jun 2023 18:50:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
>> 
>>> 138: 
>>> 139: # 0: type, 1: name
>>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
>> 
>> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.
>
> I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let me ask about this specific instance.

The language specialist confirmed the double quotes are locale specific for de.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1229881212

From naoto at openjdk.org  Wed Jun 14 16:54:02 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 16:54:02 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets() does
 not contain itself
Message-ID: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>

Adding themselves into their `contains()` method will fix it.

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

Commit messages:
 - 8167252: Some of Charset.availableCharsets() does not contain itself

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

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

From bpb at openjdk.org  Wed Jun 14 17:01:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 Jun 2023 17:01:56 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself
In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
Message-ID: <W5bKrLF2zkkH1LTLNNu5Z896li4fNc8jU2Fij1rDl2o=.4237bf16-de88-4810-8f7b-1dd2ffd29f59@github.com>

On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding themselves into their `contains()` method will fix it.

Looks all right.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1479929263

From iris at openjdk.org  Wed Jun 14 17:15:14 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 14 Jun 2023 17:15:14 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself
In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
Message-ID: <2kfcSeSvGvUD7EOTxsn1SZ5Oif1bBd1N79t_7RK4dHY=.80f0650a-8b1b-44bc-9102-575dfd00f08a@github.com>

On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding themselves into their `contains()` method will fix it.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1479949748

From alanb at openjdk.org  Wed Jun 14 17:15:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 17:15:13 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself
In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
Message-ID: <JYHAQPzEFWJFfJGj76Ssl50qtnInh3MHQUuXZ6qSFYo=.0f314abe-090b-4bf2-b653-116b1984d614@github.com>

On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding themselves into their `contains()` method will fix it.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1479944770

From lancea at openjdk.org  Wed Jun 14 17:18:58 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Jun 2023 17:18:58 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself
In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
Message-ID: <KPLPd9F-jO7FSpIodhQoh3eBm9Y0M32XLMyaFpwWt04=.0cb594de-4db8-4efe-aeb1-2f5041821c92@github.com>

On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding themselves into their `contains()` method will fix it.

Changes look fine over all.  

It might be worth considering updating this to use junit at some point as a separate clean up activity as it could further streamline the test

test/jdk/java/nio/charset/Charset/Contains.java line 108:

> 106:     }
> 107: 
> 108:     static void selfContainmentTest() {

Be nice to add a comment regarding the purpose of the test

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1479953238
PR Review Comment: https://git.openjdk.org/jdk/pull/14473#discussion_r1229937043

From alanb at openjdk.org  Wed Jun 14 17:22:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 17:22:58 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself
In-Reply-To: <KPLPd9F-jO7FSpIodhQoh3eBm9Y0M32XLMyaFpwWt04=.0cb594de-4db8-4efe-aeb1-2f5041821c92@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <KPLPd9F-jO7FSpIodhQoh3eBm9Y0M32XLMyaFpwWt04=.0cb594de-4db8-4efe-aeb1-2f5041821c92@github.com>
Message-ID: <2HdpYQwGcgeMZTqQY3zIMPch8KYRJbxmdQlNHzIWoLk=.f5449964-d30b-4a5f-b4f4-76faaa341bdb@github.com>

On Wed, 14 Jun 2023 17:14:08 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Adding themselves into their `contains()` method will fix it.
>
> test/jdk/java/nio/charset/Charset/Contains.java line 108:
> 
>> 106:     }
>> 107: 
>> 108:     static void selfContainmentTest() {
> 
> Be nice to add a comment regarding the purpose of the test

The spec is that Charset::contains return true for self so maybe it could be renamed to containsSelfTest, might help with the understanding the purpose (along with a comment)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14473#discussion_r1229943556

From naoto at openjdk.org  Wed Jun 14 17:42:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 17:42:57 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself
In-Reply-To: <2HdpYQwGcgeMZTqQY3zIMPch8KYRJbxmdQlNHzIWoLk=.f5449964-d30b-4a5f-b4f4-76faaa341bdb@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <KPLPd9F-jO7FSpIodhQoh3eBm9Y0M32XLMyaFpwWt04=.0cb594de-4db8-4efe-aeb1-2f5041821c92@github.com>
 <2HdpYQwGcgeMZTqQY3zIMPch8KYRJbxmdQlNHzIWoLk=.f5449964-d30b-4a5f-b4f4-76faaa341bdb@github.com>
Message-ID: <bRucjbHnWC9q_b0ofTjOohSzJWWfgw44PCLcJFeZPx8=.1d17d21f-5582-42b4-9bdb-66ed066895e1@github.com>

On Wed, 14 Jun 2023 17:20:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/nio/charset/Charset/Contains.java line 108:
>> 
>>> 106:     }
>>> 107: 
>>> 108:     static void selfContainmentTest() {
>> 
>> Be nice to add a comment regarding the purpose of the test
>
> The spec is that Charset::contains return true for self so maybe it could be renamed to containsSelfTest, might help with the understanding the purpose (along with a comment)

Good point. Will address these in the next iteration

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14473#discussion_r1229964387

From naoto at openjdk.org  Wed Jun 14 18:08:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 18:08:34 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
Message-ID: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>

> Adding themselves into their `contains()` method will fix it.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Refined the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14473/files
  - new: https://git.openjdk.org/jdk/pull/14473/files/89899160..bea24165

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

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

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

From alanb at openjdk.org  Wed Jun 14 18:12:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 18:12:57 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
Message-ID: <jFEkYLvt2smBHVSlYYWlnw6UaDroEf6cAIV5ryT0RT4=.b13352f2-3349-488d-ab00-e0cbb512c816@github.com>

On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding themselves into their `contains()` method will fix it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined the test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480039785

From lancea at openjdk.org  Wed Jun 14 18:36:59 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Jun 2023 18:36:59 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
Message-ID: <5IHATGaFRMSrVD-OSG1ol95xp18k8mef-iy0QhlJQwo=.ce3997b9-1d4c-49ee-a672-9e0e2dc9ba91@github.com>

On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding themselves into their `contains()` method will fix it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined the test

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480078751

From bpb at openjdk.org  Wed Jun 14 18:50:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 14 Jun 2023 18:50:57 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
Message-ID: <kecnNhkltkdaF_muKVbjINQ0ibviPKqfrlkjPD22IVc=.b131f953-d34b-49d8-bb12-21e5696f7ffb@github.com>

On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding themselves into their `contains()` method will fix it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined the test

Re-approved.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480096863

From iris at openjdk.org  Wed Jun 14 19:19:13 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 14 Jun 2023 19:19:13 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
Message-ID: <YHpxR6R1AE0eExbcYHLEZsL8GbwPbTHG_YvgATqRckQ=.363dc705-5d03-4493-aa7f-85d6efb14be2@github.com>

On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding themselves into their `contains()` method will fix it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined the test

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480141268

From jpai at openjdk.org  Thu Jun 15 06:21:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Jun 2023 06:21:58 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
Message-ID: <Bqdsi0KYwXLDuWthG0VckKReI7LzFiWaP62mhBnATy4=.b2f08a02-09c7-487a-b954-045d0a287af0@github.com>

On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding themselves into their `contains()` method will fix it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined the test

Hello Naoto, should `sun.util.PropertyResourceBundleCharset` be fixed too? Its `contains()` currently just returns `false`. Then there is `sun.font.X11Johab` in `java.desktop` module whose `contains()` appears to have a typo and is checking against an unrelated `X11GB18030_1` instance.

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

PR Comment: https://git.openjdk.org/jdk/pull/14473#issuecomment-1592434256

From alanb at openjdk.org  Thu Jun 15 06:45:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 06:45:59 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <Bqdsi0KYwXLDuWthG0VckKReI7LzFiWaP62mhBnATy4=.b2f08a02-09c7-487a-b954-045d0a287af0@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
 <Bqdsi0KYwXLDuWthG0VckKReI7LzFiWaP62mhBnATy4=.b2f08a02-09c7-487a-b954-045d0a287af0@github.com>
Message-ID: <KTotmNKGppDXxlrjJambvn79Y7kfEmojdw6jkWs3trQ=.aa447893-15a8-4462-a1ae-42863b0e6e7e@github.com>

On Thu, 15 Jun 2023 06:19:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Naoto, should `sun.util.PropertyResourceBundleCharset` be fixed too? 

This is JDK internal, it shouldn't leak out via the APIs. If there is a way for it to leak out then it would require a compliant contains method but I suspect it's internal only.

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

PR Comment: https://git.openjdk.org/jdk/pull/14473#issuecomment-1592456040

From jpai at openjdk.org  Thu Jun 15 07:23:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 15 Jun 2023 07:23:59 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
Message-ID: <dpLy99HzjZAoSfas2vsuyOw5a_FN8Ej0L2vyJvM3dtQ=.52f51be8-1274-4d0f-aefa-b820903771e3@github.com>

On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding themselves into their `contains()` method will fix it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined the test

Marked as reviewed by jpai (Reviewer).

Hello Alan,

> > Hello Naoto, should `sun.util.PropertyResourceBundleCharset` be fixed too?
> 
> This is JDK internal, it shouldn't leak out via the APIs. If there is a way for it to leak out then it would require a compliant contains method but I suspect it's internal only.

You are right this is an internal class (I just found these by checking which classes extend `Charset`). I now paid a closer attention to the title of this issue and this is more about the Charset(s) that are returned through the public API, so I think it's OK to leave these internal classes as-is at least in this PR.

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

PR Review: https://git.openjdk.org/jdk/pull/14473#pullrequestreview-1480864774
PR Comment: https://git.openjdk.org/jdk/pull/14473#issuecomment-1592498880

From naoto at openjdk.org  Thu Jun 15 16:37:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Jun 2023 16:37:12 GMT
Subject: <i18n dev> RFR: 8167252: Some of Charset.availableCharsets()
 does not contain itself [v2]
In-Reply-To: <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
 <7tCs0VlbzOjDcsih_ushdlJiQZ93_T7wyLXKfGw2aac=.d04ed135-6d99-4635-9be5-947f44b4dfe0@github.com>
Message-ID: <oCUkyO5A0pXYxuqdDa77W9z8ncu1-64qtb17dMeJRv4=.dd7425ff-bb78-4405-930e-cfb5a84daa13@github.com>

On Wed, 14 Jun 2023 18:08:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding themselves into their `contains()` method will fix it.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined the test

Thanks for the review, Jai.
As to `PropertyResourceBundleCharset`, yes it is an internal implementation as Alan mentioned, to auto detect UTF-8/ISO-8859-1, so even though `contains()` does not include itself, it is fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/14473#issuecomment-1593385179

From naoto at openjdk.org  Thu Jun 15 16:37:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Jun 2023 16:37:15 GMT
Subject: <i18n dev> Integrated: 8167252: Some of Charset.availableCharsets()
 does not contain itself
In-Reply-To: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
References: <0hOie1_jIVMQvsL7XMv0TaMulRtMz483i0QleuHw7UA=.70b8de3c-d218-458b-b6cd-5a6ef497ea07@github.com>
Message-ID: <TYgnAwB6IZXfbhpLZV7u_TVjjY0n69ExWzfYQnBgXx4=.aa534c02-a19b-4bb0-ae7d-4ddf9f6d5106@github.com>

On Wed, 14 Jun 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding themselves into their `contains()` method will fix it.

This pull request has now been integrated.

Changeset: 3eeb681a
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3eeb681a0de87baa12b6eac5966e7f707b76c8bf
Stats:     37 lines in 4 files changed: 31 ins; 0 del; 6 mod

8167252: Some of Charset.availableCharsets() does not contain itself

Reviewed-by: bpb, alanb, iris, lancea, jpai

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

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

From jlu at openjdk.org  Thu Jun 15 19:45:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 19:45:52 GMT
Subject: <i18n dev> Integrated: 8309632: JDK 21 RDP1 L10n resource files
 update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <wHemDob1LcBUGrp94CGVymYmeivv2G9ccgjfngb7m84=.a4d37dbb-54fd-4920-8734-dd2080aeaf32@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: 81bfd789
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81bfd78901ff540ad0355a466cfad097e701028a
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Thu Jun 15 19:49:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 19:49:37 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
Message-ID: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>

As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. 

In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything.

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

Commit messages:
 - Merge master and fix conflicts in Contains.java
 - Refactor CharsetContainmentTest.java
 - Remove unusued JUnit import in RegisteredCharsets.java
 - Refactor contains.java
 - Move bug id for default charset test
 - Add bug id to EncDec.java
 - Do not use wildcard import in IllegalCharsetName.java
 - Refactor RegisteredCharsets.java
 - Move default charset test to IllegalCharsetName.java
 - Refactor EncDec test to use JUnit
 - ... and 5 more: https://git.openjdk.org/jdk/compare/3e0bbd29...be352ca2

Changes: https://git.openjdk.org/jdk/pull/14500/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14500&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310049
  Stats: 2076 lines in 9 files changed: 366 ins; 447 del; 1263 mod
  Patch: https://git.openjdk.org/jdk/pull/14500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500

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

From lancea at openjdk.org  Thu Jun 15 19:58:11 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 15 Jun 2023 19:58:11 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
In-Reply-To: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
Message-ID: <s51KeLfK5lfPO9XiHs8gIkR2iXK6dtAJ3FpdSRFxl3Q=.0167a333-41cb-4566-be0a-f73f8f28ef33@github.com>

On Thu, 15 Jun 2023 19:42:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. 
> 
> In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything.

Thanks for starting this migration/refactor.

I would use this as an opportunity to add additional comments introducing the tests and the relevant parameterized lists et al

test/jdk/java/nio/charset/Charset/AvailableCharsetNames.java line 25:

> 23: 
> 24: /* @test
> 25:  * @bug 4422044 8310049

As this is just a refactor, I don't think you need the bug number for converting to junit

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

PR Review: https://git.openjdk.org/jdk/pull/14500#pullrequestreview-1482287594
PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231472262

From jlu at openjdk.org  Thu Jun 15 20:04:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 20:04:21 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v2]
In-Reply-To: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
Message-ID: <uVX9mJ3yMsMl2tqLvK9t59XAPDAFqt5CoYA20M5CX_k=.be0a98c2-1f5a-45b0-9427-fe71a3079343@github.com>

> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. 
> 
> In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything.

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

  Review: Refactoring does not require bugID in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14500/files
  - new: https://git.openjdk.org/jdk/pull/14500/files/be352ca2..eb374d64

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

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

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

From jlu at openjdk.org  Thu Jun 15 20:04:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 20:04:24 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v2]
In-Reply-To: <s51KeLfK5lfPO9XiHs8gIkR2iXK6dtAJ3FpdSRFxl3Q=.0167a333-41cb-4566-be0a-f73f8f28ef33@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
 <s51KeLfK5lfPO9XiHs8gIkR2iXK6dtAJ3FpdSRFxl3Q=.0167a333-41cb-4566-be0a-f73f8f28ef33@github.com>
Message-ID: <tc6c8KTAxOpc3RuY6mv-0iFkagf3KWAuMm_09bU1l5E=.ada778be-1c0c-4903-870b-694b0754997a@github.com>

On Thu, 15 Jun 2023 19:52:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Refactoring does not require bugID in test
>
> test/jdk/java/nio/charset/Charset/AvailableCharsetNames.java line 25:
> 
>> 23: 
>> 24: /* @test
>> 25:  * @bug 4422044 8310049
> 
> As this is just a refactor, I don't think you need the bug number for converting to junit

Fixed, in this file and the others

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231478728

From kcr at openjdk.org  Thu Jun 15 20:05:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 20:05:30 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <lk-HQVh3RGdNHbBiHftYiYZQzEq5Hp6CCtCXPjSbAPs=.ae8c0707-7daf-4142-8147-1ea24323364a@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

I was 

> @kevinrushforth Thanks for the reminder, will make the change in ML first.

Thanks. And I see you made this PR Draft, which is a good idea. Once the mainline PR is integrated, you can change the title of this PR to `Backport NNNNNNNNNNN`, where `NNNNNNNNNNN` is the 40 character commit hash of the jdk master commit. Then Skara will note this as a Backport, and also note whether it is a clean backport.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588176435

From duke at openjdk.org  Thu Jun 15 20:05:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 15 Jun 2023 20:05:31 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <j-x2Vg89HAUcCaDz51mqofqhoX932hkfEGlaF-FvKIo=.8473b365-250a-47c3-b052-9d78947374de@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

(Review comment moved to mainline PR)

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

PR Review Comment: https://git.openjdk.org/jdk21/pull/11#discussion_r1227287139

From jlu at openjdk.org  Thu Jun 15 20:48:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 20:48:38 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v3]
In-Reply-To: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
Message-ID: <rwDWFm1FTRk6MCcM6HFFYfINnV3j3qp6dBR5--Put_8=.378ce3fc-40c2-4562-8f5d-24e3ae1d96a5@github.com>

> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. 
> 
> In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything.

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

 - Review: Clarify RegisteredCharsets.java and add comments to test methods
 - Minor cleanup
 - Refactor IllegalCharsetName.java to use method source
 - Update EncDec.java to be more informative + cautious
 - Update data source: other -> standard Charsets
 - Review: Add comments to Contains.java to explain each test
 - Review: Add comment for test in AvailableCharsetNames.java
 - Review: Make CharsetContainmentTest.java data source and test method more clear

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14500/files
  - new: https://git.openjdk.org/jdk/pull/14500/files/eb374d64..6c7a8d05

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

  Stats: 108 lines in 6 files changed: 70 ins; 14 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/14500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500

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

From kcr at openjdk.org  Thu Jun 15 21:09:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 21:09:09 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593724465

From jlu at openjdk.org  Thu Jun 15 21:13:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 21:13:00 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
Message-ID: <8055MPxK8nGDItLuewscD0HhRwu4yJHWRoWg1H_SEu4=.7a2b5b3b-422c-4d32-8b68-d856a6ac8c05@github.com>

On Thu, 15 Jun 2023 21:06:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

Hi Kevin, yes it is. I still need to grab the changes from mainline and include them in this PR.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593728784

From naoto at openjdk.org  Thu Jun 15 22:29:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Jun 2023 22:29:06 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v3]
In-Reply-To: <rwDWFm1FTRk6MCcM6HFFYfINnV3j3qp6dBR5--Put_8=.378ce3fc-40c2-4562-8f5d-24e3ae1d96a5@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
 <rwDWFm1FTRk6MCcM6HFFYfINnV3j3qp6dBR5--Put_8=.378ce3fc-40c2-4562-8f5d-24e3ae1d96a5@github.com>
Message-ID: <lJYeKm4TyvlKCPTJ0nPvT6mFJcu0xI9DS8LmnuSA_34=.e99ebb58-2d87-4a3f-91e5-115a6b19d046@github.com>

On Thu, 15 Jun 2023 20:48:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. 
>> 
>> In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything.
>
> Justin Lu has updated the pull request incrementally with eight additional commits since the last revision:
> 
>  - Review: Clarify RegisteredCharsets.java and add comments to test methods
>  - Minor cleanup
>  - Refactor IllegalCharsetName.java to use method source
>  - Update EncDec.java to be more informative + cautious
>  - Update data source: other -> standard Charsets
>  - Review: Add comments to Contains.java to explain each test
>  - Review: Add comment for test in AvailableCharsetNames.java
>  - Review: Make CharsetContainmentTest.java data source and test method more clear

Thanks for the clean-up. Some comments follow:

test/jdk/java/nio/charset/Charset/Contains.java line 51:

> 49:     @ParameterizedTest
> 50:     @MethodSource("standardCharsets")
> 51:     public void standardCharsetsTest(Charset containerCs, Charset cs, boolean cont){

`ISO-8859-15` and `CP1252` are not `StandardCharsets` so renaming the method to standardCharsetsTest seems incorrect.

test/jdk/java/nio/charset/Charset/Default.java line 1:

> 1: /*

This class is used in `DefaultCharsetTest` so don't remove it.

test/jdk/java/nio/charset/Charset/IllegalCharsetName.java line 51:

> 49:         assertThrows(UnsupportedCharsetException.class,
> 50:                 () -> Charset.forName("default"));
> 51:     }

Seems incorrect to merge this test into `IllegalCharsetName.java` because it is throwing `UnsupportedCharsetException`.

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

PR Review: https://git.openjdk.org/jdk/pull/14500#pullrequestreview-1482442857
PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231572797
PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231585756
PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231594567

From jlu at openjdk.org  Thu Jun 15 23:09:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 23:09:24 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v4]
In-Reply-To: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
Message-ID: <fIKb4-UOkr5OAUoa-JoguW9xALsbQRdYQnX3MxZUjU4=.4b9f649d-59c9-4d79-983a-8ec842c406ac@github.com>

> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit. 
> 
> In addition, this PR groups the emptyCharset, nullCharset, and defaultCharset tests into _illegalCharsets.java_. The _default.java_ file was removed, as it did not test anything.

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

 - Review: Move default test back to RegisteredCharsets.java
 - Review: rename standard charsets test
 - Revert "Remove Default test"
   
   This reverts commit 346cb4c050adb8bd8a3cb942e25a98484703b997.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14500/files
  - new: https://git.openjdk.org/jdk/pull/14500/files/6c7a8d05..6a39ceab

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

  Stats: 61 lines in 4 files changed: 46 ins; 8 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500

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

From jlu at openjdk.org  Thu Jun 15 23:09:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 23:09:24 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v3]
In-Reply-To: <lJYeKm4TyvlKCPTJ0nPvT6mFJcu0xI9DS8LmnuSA_34=.e99ebb58-2d87-4a3f-91e5-115a6b19d046@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
 <rwDWFm1FTRk6MCcM6HFFYfINnV3j3qp6dBR5--Put_8=.378ce3fc-40c2-4562-8f5d-24e3ae1d96a5@github.com>
 <lJYeKm4TyvlKCPTJ0nPvT6mFJcu0xI9DS8LmnuSA_34=.e99ebb58-2d87-4a3f-91e5-115a6b19d046@github.com>
Message-ID: <YO1r0KpTndAGA4M6Yvpfpa-5SvgoCLpJ1aTlwvwLB4k=.99697e3f-bddf-40ca-af69-8837ab4053f5@github.com>

On Thu, 15 Jun 2023 21:58:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with eight additional commits since the last revision:
>> 
>>  - Review: Clarify RegisteredCharsets.java and add comments to test methods
>>  - Minor cleanup
>>  - Refactor IllegalCharsetName.java to use method source
>>  - Update EncDec.java to be more informative + cautious
>>  - Update data source: other -> standard Charsets
>>  - Review: Add comments to Contains.java to explain each test
>>  - Review: Add comment for test in AvailableCharsetNames.java
>>  - Review: Make CharsetContainmentTest.java data source and test method more clear
>
> test/jdk/java/nio/charset/Charset/Contains.java line 51:
> 
>> 49:     @ParameterizedTest
>> 50:     @MethodSource("standardCharsets")
>> 51:     public void standardCharsetsTest(Charset containerCs, Charset cs, boolean cont){
> 
> `ISO-8859-15` and `CP1252` are not `StandardCharsets` so renaming the method to standardCharsetsTest seems incorrect.

Did not realize, thank you. I simply renamed it to charsets (as I am not sure if those tested are supposed to represent a particular group, or if they are just random).

> test/jdk/java/nio/charset/Charset/IllegalCharsetName.java line 51:
> 
>> 49:         assertThrows(UnsupportedCharsetException.class,
>> 50:                 () -> Charset.forName("default"));
>> 51:     }
> 
> Seems incorrect to merge this test into `IllegalCharsetName.java` because it is throwing `UnsupportedCharsetException`.

I moved it back to RegisteredCharsets.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231612571
PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231612904

From jlu at openjdk.org  Thu Jun 15 23:09:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 23:09:25 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v4]
In-Reply-To: <lJYeKm4TyvlKCPTJ0nPvT6mFJcu0xI9DS8LmnuSA_34=.e99ebb58-2d87-4a3f-91e5-115a6b19d046@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
 <rwDWFm1FTRk6MCcM6HFFYfINnV3j3qp6dBR5--Put_8=.378ce3fc-40c2-4562-8f5d-24e3ae1d96a5@github.com>
 <lJYeKm4TyvlKCPTJ0nPvT6mFJcu0xI9DS8LmnuSA_34=.e99ebb58-2d87-4a3f-91e5-115a6b19d046@github.com>
Message-ID: <cYjJd4UhdmpzEtV9pyn7bOoufFgboEP2jATW8GpE3C0=.f063bbe2-c28b-448a-afdd-793fb6cfaf2d@github.com>

On Thu, 15 Jun 2023 22:11:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Review: Move default test back to RegisteredCharsets.java
>>  - Review: rename standard charsets test
>>  - Revert "Remove Default test"
>>    
>>    This reverts commit 346cb4c050adb8bd8a3cb942e25a98484703b997.
>
> test/jdk/java/nio/charset/Charset/Default.java line 1:
> 
>> (failed to retrieve contents of file, check the PR for context)
> This class is used in `DefaultCharsetTest` so don't remove it.

Fixed, thank you

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1231612681

From jlu at openjdk.org  Fri Jun 16 04:39:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 04:39:42 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

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

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value
 - Review: use Naoto's recommended ja values
 - Revert 'main.help.opt.any.file' value for _de

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

Changes:
  - all: https://git.openjdk.org/jdk21/pull/11/files
  - new: https://git.openjdk.org/jdk21/pull/11/files/13b8b309..a2e52373

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

  Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

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

From duke at openjdk.org  Fri Jun 16 12:14:04 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 12:14:04 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v3]
In-Reply-To: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
Message-ID: <CYiUcWIBmpqDZBnDtPrS0da8Evu0Xm9VOUOgA1yr5_Q=.a0ac9e38-9f75-4eca-b078-e8f48add366f@github.com>

On Tue, 13 Jun 2023 17:56:57 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 incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

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

> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),

don't lines 147 and 148 above already guarantee the language and region have correct case?

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

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

From duke at openjdk.org  Fri Jun 16 12:49:06 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 12:49:06 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v3]
In-Reply-To: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
Message-ID: <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>

On Tue, 13 Jun 2023 17:56:57 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 incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

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

> 166:         // BaseLocale as the key. The returned "normalized" instance
> 167:         // can subsequently be used by the Locale instance which
> 168:         // guarantees the locale components are properly cased/interned.

Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.




    public static BaseLocale getInstance(String language, String script,
                                         String region, String variant) {
        if (script == null) {
            script = "";
        } else {
            script = getCanonicalString(script, LocaleUtils::toTitleString);
        }

        if (region == null) {
            region = "";
        } else {
            region = getCanonicalString(region, LocaleUtils::toUpperString);
        }

        if (language == null) {
            language = "";
        } else {
            language = getCanonicalString(language, LocaleUtils::toLowerString);
        }
        
        if (variant == null) {
            variant = "";
        } else {
            variant = getCanonicalString(variant, Function.identity());
        }
        ...
        return new BaseLocale(language, script, region, variant);
    }



    private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();

    static {
        // prime the old iso codes
        CANONICALIZED_STRINGS.put("he", "he");
        CANONICALIZED_STRINGS.put("iw", "iw");
        CANONICALIZED_STRINGS.put("id", "id");
        CANONICALIZED_STRINGS.put("in", "in");
        CANONICALIZED_STRINGS.put("ji", "ji");
        CANONICALIZED_STRINGS.put("yi", "yi");
    }
    
    private static String getCanonicalString(String value, Function<String, String> conversion) {
        String existing = CANONICALIZED_STRINGS.get(value);
        if (existing != null) {
            return existing;
        }

        String converted = conversion.apply(value);
        return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);
    }

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

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

From jjg at openjdk.org  Fri Jun 16 15:09:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 16 Jun 2023 15:09:14 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>

On Tue, 13 Jun 2023 18:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594844435

From naoto at openjdk.org  Fri Jun 16 17:16:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:16:33 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
Message-ID: <mnwQXQ-yvvAdB4JlfTC3NwMpbuEENwDTX0GeETglGh0=.9054a675-049f-4dfb-a847-4e93fea5020f@github.com>

On Fri, 16 Jun 2023 15:06:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
>
>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
> 
> 1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
> 2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.
> 3. The iteration order would be undefined when resources are removed from one or more resource files

Makes sense. Thanks for the explanation @jonathan-gibbons

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594999086

From naoto at openjdk.org  Fri Jun 16 17:22:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:22:04 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v3]
In-Reply-To: <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
Message-ID: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>

On Fri, 16 Jun 2023 12:46:01 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:
> 
>> 166:         // BaseLocale as the key. The returned "normalized" instance
>> 167:         // can subsequently be used by the Locale instance which
>> 168:         // guarantees the locale components are properly cased/interned.
> 
> Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
> my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.
> 
> 
> 
> 
>     public static BaseLocale getInstance(String language, String script,
>                                          String region, String variant) {
>         if (script == null || script.isEmpty()) {
>             script = "";
>         } else {
>             script = getCanonicalString(script, LocaleUtils::toTitleString);
>         }
> 
>         if (region == null || region.isEmpty()) {
>             region = "";
>         } else {
>             region = getCanonicalString(region, LocaleUtils::toUpperString);
>         }
> 
>         if (language == null || language.isEmpty()) {
>             language = "";
>         } else {
>             language = getCanonicalString(language, LocaleUtils::toLowerString);
>         }
>         
>         if (variant == null || variant.isEmpty()) {
>             variant = "";
>         } else {
>             variant = getCanonicalString(variant, Function.identity());
>         }
>         ...
>         return new BaseLocale(language, script, region, variant);
>     }
> 
> 
> 
>     private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();
> 
>     static {
>         // prime the old iso codes
>         CANONICALIZED_STRINGS.put("he", "he");
>         CANONICALIZED_STRINGS.put("iw", "iw");
>         CANONICALIZED_STRINGS.put("id", "id");
>         CANONICALIZED_STRINGS.put("in", "in");
>         CANONICALIZED_STRINGS.put("ji", "ji");
>         CANONICALIZED_STRINGS.put("yi", "yi");
>     }
>     
>     private static String getCanonicalString(String value, Function<String, String> conversion) {
>         String existing = CANONICALIZED_STRINGS.get(value);
>         if (existing != null) {
>             return existing;
>         }
> 
>         String converted = conversion.apply(value);
>         return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);
>     }

Interning components in a Locale instance (through BaseLocale) is a long standing behavior. Changing it could break apps that might have relied on it (using `==` for comparison)

> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:
> 
>> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
>> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
>> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),
> 
> don't lines 147 and 148 above already guarantee the language and region have correct case?

147,148 are in `getInstance()` and the BaseLocale key here is created with a constructor, which simply copies the passed arguments. So normalization is needed here

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

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

From naoto at openjdk.org  Fri Jun 16 17:41:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:41:03 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v4]
In-Reply-To: <fIKb4-UOkr5OAUoa-JoguW9xALsbQRdYQnX3MxZUjU4=.4b9f649d-59c9-4d79-983a-8ec842c406ac@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
 <fIKb4-UOkr5OAUoa-JoguW9xALsbQRdYQnX3MxZUjU4=.4b9f649d-59c9-4d79-983a-8ec842c406ac@github.com>
Message-ID: <A4fUgCxE2q-NnJnm0LnN4fBkK81_sXhlvILjAwhiAao=.ef01c591-4737-4eab-914c-fe867f8f369c@github.com>

On Thu, 15 Jun 2023 23:09:24 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: Move default test back to RegisteredCharsets.java
>  - Review: rename standard charsets test
>  - Revert "Remove Default test"
>    
>    This reverts commit 346cb4c050adb8bd8a3cb942e25a98484703b997.

test/jdk/java/nio/charset/Charset/IllegalCharsetName.java line 50:

> 48:         assertThrows(IllegalArgumentException.class,
> 49:                 () -> Charset.forName(null));
> 50:     }

Missed this one previously. This one is also not `IllegalCharsetName`, so I'd prefer not to merge this either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1232543764

From jlu at openjdk.org  Fri Jun 16 18:23:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 18:23:40 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v4]
In-Reply-To: <A4fUgCxE2q-NnJnm0LnN4fBkK81_sXhlvILjAwhiAao=.ef01c591-4737-4eab-914c-fe867f8f369c@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
 <fIKb4-UOkr5OAUoa-JoguW9xALsbQRdYQnX3MxZUjU4=.4b9f649d-59c9-4d79-983a-8ec842c406ac@github.com>
 <A4fUgCxE2q-NnJnm0LnN4fBkK81_sXhlvILjAwhiAao=.ef01c591-4737-4eab-914c-fe867f8f369c@github.com>
Message-ID: <lvH48mh25AE7nHHo9Rrys6kTNXs_QKnFcnUQKxig7Ig=.eebb1bf7-7de7-448b-800f-6e43e08ca69f@github.com>

On Fri, 16 Jun 2023 17:36:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Review: Move default test back to RegisteredCharsets.java
>>  - Review: rename standard charsets test
>>  - Revert "Remove Default test"
>>    
>>    This reverts commit 346cb4c050adb8bd8a3cb942e25a98484703b997.
>
> test/jdk/java/nio/charset/Charset/IllegalCharsetName.java line 50:
> 
>> 48:         assertThrows(IllegalArgumentException.class,
>> 49:                 () -> Charset.forName(null));
>> 50:     }
> 
> Missed this one previously. This one is also not `IllegalCharsetName`, so I'd prefer not to merge this either.

I guess when I think of illegal (I group anything that is _wrong_, so I initially included null and "default"). But you are right that it does not throw IllegalCharsetNameException so it should be moved into its own test. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14500#discussion_r1232588591

From jlu at openjdk.org  Fri Jun 16 18:23:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 18:23:40 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v5]
In-Reply-To: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
Message-ID: <Mb2bevQoDjF_rrk5X4URmsAEjfHX9WZ0diIO7JfNd14=.9cab1223-d089-4325-ab7f-ac1197ed171f@github.com>

> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit.

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

  Review: Make null charset its own test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14500/files
  - new: https://git.openjdk.org/jdk/pull/14500/files/6a39ceab..bc50c6f5

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

  Stats: 52 lines in 2 files changed: 44 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14500/head:pull/14500

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

From naoto at openjdk.org  Fri Jun 16 18:35:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 18:35:10 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v5]
In-Reply-To: <Mb2bevQoDjF_rrk5X4URmsAEjfHX9WZ0diIO7JfNd14=.9cab1223-d089-4325-ab7f-ac1197ed171f@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
 <Mb2bevQoDjF_rrk5X4URmsAEjfHX9WZ0diIO7JfNd14=.9cab1223-d089-4325-ab7f-ac1197ed171f@github.com>
Message-ID: <LF782D_KRGXCbTpZUbSmyjpuJiJ85QF_H8gSXXc8SpE=.6e07fbc8-9685-43f1-8cfb-9110dad20319@github.com>

On Fri, 16 Jun 2023 18:23:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Make null charset its own test

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14500#pullrequestreview-1484108191

From lancea at openjdk.org  Fri Jun 16 19:29:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Jun 2023 19:29:21 GMT
Subject: <i18n dev> RFR: 8310049: Refactor Charset tests to use JUnit
 [v5]
In-Reply-To: <Mb2bevQoDjF_rrk5X4URmsAEjfHX9WZ0diIO7JfNd14=.9cab1223-d089-4325-ab7f-ac1197ed171f@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
 <Mb2bevQoDjF_rrk5X4URmsAEjfHX9WZ0diIO7JfNd14=.9cab1223-d089-4325-ab7f-ac1197ed171f@github.com>
Message-ID: <TS_CG5dRt6kwTcUzH-YfEBEn5soy0SLxlg5h5FVnAYI=.e99e1f36-62f5-42a6-8129-5f2b32f3c861@github.com>

On Fri, 16 Jun 2023 18:23:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Make null charset its own test

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14500#pullrequestreview-1484203706

From rriggs at openjdk.org  Fri Jun 16 19:31:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 19:31:22 GMT
Subject: <i18n dev> RFR: 8310033: Clarify return value of Java Time
 compareTo methods
Message-ID: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>

In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
Add javadoc @see tags to isBefore and isAfter methods

Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
The term "positive" is ambiguous, zero is considered positive and indicates equality.

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

Commit messages:
 - Clarify for Duration, AbstractChronology, and Chronology
 - Correct javadoc of compareInstant
 - 8310033: Improve Instant.compareTo javadoc to mention before and after

Changes: https://git.openjdk.org/jdk/pull/14479/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310033
  Stats: 60 lines in 17 files changed: 42 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/14479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14479/head:pull/14479

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

From naoto at openjdk.org  Fri Jun 16 21:02:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 21:02:17 GMT
Subject: <i18n dev> RFR: 8309632: JDK 21 RDP1 L10n resource files update
 [v2]
In-Reply-To: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
Message-ID: <Jfrbn9kav_htg9Xsi2K0qX_DMxUTs4QAEzMKI77gj-4=.089cfa89-dcf3-4441-817b-f6a575cb4d9c@github.com>

On Fri, 16 Jun 2023 04:39:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value
>  - Review: use Naoto's recommended ja values
>  - Revert 'main.help.opt.any.file' value for _de

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/11#pullrequestreview-1484380340

From jlu at openjdk.org  Fri Jun 16 21:14:20 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 21:14:20 GMT
Subject: <i18n dev> Integrated: 8309632: JDK 21 RDP1 L10n resource files
 update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <yxBFAdo-tYodL8exo3y2xbRz6pYcTIvYVJ8Tnbzp1WM=.80ad659c-02ea-476d-8e2a-ed80b3187880@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: a1c1d97a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a1c1d97a4e07bae872b5608b4d8d8f85195edd82
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto
Backport-of: 81bfd78901ff540ad0355a466cfad097e701028a

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

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

From duke at openjdk.org  Fri Jun 16 23:07:09 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 23:07:09 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v3]
In-Reply-To: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
 <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
Message-ID: <kgHbRjygYOWymroVUQRzMTvBORaS1xA1oNntD5JLAC8=.fc94b5c2-7e76-4eea-842e-aa1416c96cc6@github.com>

On Fri, 16 Jun 2023 17:18:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:
>> 
>>> 166:         // BaseLocale as the key. The returned "normalized" instance
>>> 167:         // can subsequently be used by the Locale instance which
>>> 168:         // guarantees the locale components are properly cased/interned.
>> 
>> Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
>> my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.
>> 
>> 
>> 
>> 
>>     public static BaseLocale getInstance(String language, String script,
>>                                          String region, String variant) {
>>         if (script == null || script.isEmpty()) {
>>             script = "";
>>         } else {
>>             script = getCanonicalString(script, LocaleUtils::toTitleString);
>>         }
>> 
>>         if (region == null || region.isEmpty()) {
>>             region = "";
>>         } else {
>>             region = getCanonicalString(region, LocaleUtils::toUpperString);
>>         }
>> 
>>         if (language == null || language.isEmpty()) {
>>             language = "";
>>         } else {
>>             language = getCanonicalString(language, LocaleUtils::toLowerString);
>>         }
>>         
>>         if (variant == null || variant.isEmpty()) {
>>             variant = "";
>>         } else {
>>             variant = getCanonicalString(variant, Function.identity());
>>         }
>>         ...
>>         return new BaseLocale(language, script, region, variant);
>>     }
>> 
>> 
>> 
>>     private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();
>> 
>>     static {
>>         // prime the old iso codes
>>         CANONICALIZED_STRINGS.put("he", "he");
>>         CANONICALIZED_STRINGS.put("iw", "iw");
>>         CANONICALIZED_STRINGS.put("id", "id");
>>         CANONICALIZED_STRINGS.put("in", "in");
>>         CANONICALIZED_STRINGS.put("ji", "ji");
>>         CANONICALIZED_STRINGS.put("yi", "yi");
>>     }
>>     
>>     private static String getCanonicalString(String value, Function<String, String> conversion) {
>>         String existing = CANONICALIZED_STRINGS.get(value);
>>         if (existing != null) {
>>             return existing;
>>         }
>> 
>>         String converted = conversion.apply(value);
>>         return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);...
>
> Interning components in a Locale instance (through BaseLocale) is a long standing behavior. Changing it could break apps that might have relied on it (using `==` for comparison)

as in doing `"en" == locale.getLanguage()`?

In that case, the interned values could still be used as the canonical values, and the CHM can account both for case adjustments and interning (and likely faster than actually calling intern). I am curious how this does with your jmh test:



    private static final ConcurrentMap<String, String> CANONICALIZED_UPPER_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_LOWER_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_TITLE_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();

    public static BaseLocale getInstance(String language, String script,
                                         String region, String variant) {
        if (script == null || script.isEmpty()) {
            script = "";
        } else {
            script = getCanonicalString(script, LocaleUtils::toTitleString, CANONICALIZED_TITLE_STRINGS);
        }

        if (region == null || region.isEmpty()) {
            region = "";
        } else {
            region = getCanonicalString(region, LocaleUtils::toUpperString, CANONICALIZED_UPPER_STRINGS);
        }

        if (language == null || language.isEmpty()) {
            language = "";
        } else {
            language = getCanonicalString(language, LocaleUtils::toLowerString, CANONICALIZED_LOWER_STRINGS);
        }

        if (variant == null || variant.isEmpty()) {
            variant = "";
        } else {
            variant = getCanonicalString(variant, Function.identity(), CANONICALIZED_STRINGS);
        }
        ...
        return new BaseLocale(language, script, region, variant);
    }

    private static String getCanonicalString(String value, Function<String, String> conversion, ConcurrentMap<String, String> map) {
        String existing = map.get(value);
        if (existing != null) {
            return existing;
        }

        String converted = conversion.apply(value).intern();
        // put the interned value in, keyed by the interned value
        map.putIfAbsent(converted, converted);

        // also put the interned value in for the given key, if not already present
        // this avoids future needs to apply a conversion to the value
        map.putIfAbsent(value, converted);
        return converted;
    }

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

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

From duke at openjdk.org  Fri Jun 16 23:42:07 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 23:42:07 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v3]
In-Reply-To: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
 <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
Message-ID: <gWkti9DR72RUYx0_08o08TjJdRAyWEZkQz5EWDkqKqE=.ad60c779-36d8-43b4-be52-5b0a8f72ffb7@github.com>

On Fri, 16 Jun 2023 17:18:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:
>> 
>>> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
>>> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
>>> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),
>> 
>> don't lines 147 and 148 above already guarantee the language and region have correct case?
>
> 147,148 are in `getInstance()` and the BaseLocale key here is created with a constructor, which simply copies the passed arguments. So normalization is needed here

perhaps I am missing something, but aren't `language` and `region` being reassigned to the case adjusted values? So the values used to create the "key" BaseLocale instance reflect that case adjustment? (language is again potentially adjusted at line 162 to account for old iso codes, but that never results in the wrong case.)


        language = LocaleUtils.toLowerString(language);
        region = LocaleUtils.toUpperString(region);

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

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

From jlu at openjdk.org  Tue Jun 20 17:24:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 Jun 2023 17:24:22 GMT
Subject: <i18n dev> Integrated: 8310049: Refactor Charset tests to use JUnit
In-Reply-To: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
References: <FYOjfKlSL1CXa5ppHLdrYv8mqtzToSOgYcV0pRfamT0=.6c0f1cb2-3cbb-473c-8593-abae95f991f4@github.com>
Message-ID: <69tck2mSw8WVRxfMiPDhjXxwJKk6gEINqBC-d4Xogz4=.50adc537-44dc-41fa-84bd-506ee0c4a637@github.com>

On Thu, 15 Jun 2023 19:42:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/14473/files, tests within _test/jdk/java/nio/charset/Charset_ could benefit from using a test framework such as JUnit.

This pull request has now been integrated.

Changeset: 09174e0c
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/09174e0c994dfb19fd09f551720c13c6479812d4
Stats:     2072 lines in 8 files changed: 425 ins; 376 del; 1271 mod

8310049: Refactor Charset tests to use JUnit

Reviewed-by: lancea, naoto

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

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

From jlu at openjdk.org  Thu Jun 22 01:16:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 01:16:33 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit
Message-ID: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>

Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.

If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).

Below is a list of all the changes,

- Refactor Bug4316602.java as LocaleConstructors.java
- Refactor Bug4210525.java as CaseCheckVariant.java
- Refactor bug6277243.java as RootLocale.java
- Refactor bug6312358.java as GetInstanceCheck.java
- Refactor Bug8154797.java as CompareProviderFormats.java
- Refactor Bug8004240.java as GetAdapterPreference.java
- Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

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

Commit messages:
 - Minor cleanup to various files
 - Refactor Bug8004240.java as GetAdapterPreference.java
 - Revert "Rename bug4123285.java as LocalesInApplet.java + minor cleanup, do not refactor to junit as depends on Applet"
 - Typo in CompareProviderFormats.java
 - Refactor Bug8154797.java as CompareProviderFormats.java
 - Rename bug4123285.java as LocalesInApplet.java + minor cleanup, do not refactor to junit as depends on Applet
 - Refactor bug6312358.java as GetInstanceCheck.java
 - Refactor bug6277243.java as RootLocale.java
 - Case of vars in LocaleConstructors.java
 - Refactor Bug4210525 as CaseCheckVariant
 - ... and 4 more: https://git.openjdk.org/jdk/compare/3e0bbd29...02252fb5

Changes: https://git.openjdk.org/jdk/pull/14609/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310234
  Stats: 1104 lines in 15 files changed: 597 ins; 507 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14609/head:pull/14609

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

From jlu at openjdk.org  Thu Jun 22 18:28:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 18:28:03 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <ITX09ODwahJGWJ2arRKHETAk7Y3hJKVrEa7cb4iK86Y=.1f1c8d1a-3c31-4a89-9d49-b38962c4bbc5@github.com>

On Thu, 22 Jun 2023 01:08:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

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

> 49:     public void langTest() {
> 50:         Locale aLocale = Locale.of(LANG);
> 51:         Locale otherLocale = new Locale(LANG);

Is there a preference on testing code that is marked as `@deprecated` in the JDK? This test originally validated the parameters of the deprecated Locale constructor but was changed in 2022 with the Locale.of() method. However, the test was originally meant to test the constructor so I re-inserted it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238889219

From lancea at openjdk.org  Thu Jun 22 18:34:03 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 Jun 2023 18:34:03 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit
In-Reply-To: <ITX09ODwahJGWJ2arRKHETAk7Y3hJKVrEa7cb4iK86Y=.1f1c8d1a-3c31-4a89-9d49-b38962c4bbc5@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <ITX09ODwahJGWJ2arRKHETAk7Y3hJKVrEa7cb4iK86Y=.1f1c8d1a-3c31-4a89-9d49-b38962c4bbc5@github.com>
Message-ID: <qHlJqSbpWXiMHGXIFVlzEytrpvC0vMv3s-aVy5ZqwyI=.7590836e-5345-4f2d-bd1b-c9af114f1a6c@github.com>

On Thu, 22 Jun 2023 18:25:24 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
>> 
>> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
>> 
>> Below is a list of all the changes,
>> 
>> - Refactor Bug4316602.java as LocaleConstructors.java
>> - Refactor Bug4210525.java as CaseCheckVariant.java
>> - Refactor bug6277243.java as RootLocale.java
>> - Refactor bug6312358.java as GetInstanceCheck.java
>> - Refactor Bug8154797.java as CompareProviderFormats.java
>> - Refactor Bug8004240.java as GetAdapterPreference.java
>> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)
>
> test/jdk/java/util/Locale/LocaleConstructors.java line 51:
> 
>> 49:     public void langTest() {
>> 50:         Locale aLocale = Locale.of(LANG);
>> 51:         Locale otherLocale = new Locale(LANG);
> 
> Is there a preference on testing code that is marked as `@deprecated` in the JDK? This test originally validated the parameters of the deprecated Locale constructor but was changed in 2022 with the Locale.of() method. However, the test was originally meant to test the constructor so I re-inserted it here.

If the functionality still exists we should keep the existing test(s)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238894306

From lancea at openjdk.org  Thu Jun 22 18:38:03 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 Jun 2023 18:38:03 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <gKWqR92gEv-2EG_F3W9y10ljpWKfdrRukPVYppE0CB4=.d7207626-9f86-4691-8ca1-4e59e1133e1e@github.com>

On Thu, 22 Jun 2023 01:08:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

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

> 54:     }
> 55: 
> 56:     @Test

Minor, but please consider a simple comment describing the tests intent.  Just makes it easier for future developers...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238897495

From jlu at openjdk.org  Thu Jun 22 18:55:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 18:55:31 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v2]
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

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

  Review: Clarify LocaleConstructors.java with comment for each test method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14609/files
  - new: https://git.openjdk.org/jdk/pull/14609/files/02252fb5..63256db3

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

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

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

From jlu at openjdk.org  Thu Jun 22 18:55:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 18:55:32 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v2]
In-Reply-To: <qHlJqSbpWXiMHGXIFVlzEytrpvC0vMv3s-aVy5ZqwyI=.7590836e-5345-4f2d-bd1b-c9af114f1a6c@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <ITX09ODwahJGWJ2arRKHETAk7Y3hJKVrEa7cb4iK86Y=.1f1c8d1a-3c31-4a89-9d49-b38962c4bbc5@github.com>
 <qHlJqSbpWXiMHGXIFVlzEytrpvC0vMv3s-aVy5ZqwyI=.7590836e-5345-4f2d-bd1b-c9af114f1a6c@github.com>
Message-ID: <Z7-9eG9QwfxTZfISAFMPhBzqGMYMxpD9n6-tbt-3Wpk=.37da95b5-d2a3-4531-8efd-e5053978649c@github.com>

On Thu, 22 Jun 2023 18:30:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/util/Locale/LocaleConstructors.java line 51:
>> 
>>> 49:     public void langTest() {
>>> 50:         Locale aLocale = Locale.of(LANG);
>>> 51:         Locale otherLocale = new Locale(LANG);
>> 
>> Is there a preference on testing code that is marked as `@deprecated` in the JDK? This test originally validated the parameters of the deprecated Locale constructor but was changed in 2022 with the Locale.of() method. However, the test was originally meant to test the constructor so I re-inserted it here.
>
> If the functionality still exists we should keep the existing test(s)

Got it, will leave it in then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238912827

From jlu at openjdk.org  Thu Jun 22 18:55:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 18:55:56 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v2]
In-Reply-To: <gKWqR92gEv-2EG_F3W9y10ljpWKfdrRukPVYppE0CB4=.d7207626-9f86-4691-8ca1-4e59e1133e1e@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <gKWqR92gEv-2EG_F3W9y10ljpWKfdrRukPVYppE0CB4=.d7207626-9f86-4691-8ca1-4e59e1133e1e@github.com>
Message-ID: <yxjKX0T-P_sF7iHbul4vQ5RidcC0xZ8kJQKx5Y4-Reg=.01d1cb00-a402-4d57-b528-43efb092757d@github.com>

On Thu, 22 Jun 2023 18:34:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Clarify LocaleConstructors.java with comment for each test method
>
> test/jdk/java/util/Locale/LocaleConstructors.java line 56:
> 
>> 54:     }
>> 55: 
>> 56:     @Test
> 
> Minor, but please consider a simple comment describing the tests intent.  Just makes it easier for future developers...

Had originally only included a blanket comment for the test class. Updated the file with a comment for each test method to clarify intent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238915682

From naoto at openjdk.org  Thu Jun 22 19:15:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Jun 2023 19:15:09 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v2]
In-Reply-To: <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
Message-ID: <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>

On Thu, 22 Jun 2023 18:55:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
>> 
>> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
>> 
>> Below is a list of all the changes,
>> 
>> - Refactor Bug4316602.java as LocaleConstructors.java
>> - Refactor Bug4210525.java as CaseCheckVariant.java
>> - Refactor bug6277243.java as RootLocale.java
>> - Refactor bug6312358.java as GetInstanceCheck.java
>> - Refactor Bug8154797.java as CompareProviderFormats.java
>> - Refactor Bug8004240.java as GetAdapterPreference.java
>> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Clarify LocaleConstructors.java with comment for each test method

test/jdk/java/util/Locale/AvailableLocalesTest.java line 46:

> 44:     /**
> 45:      * Test that Locale.getAvailableLocales() is non-empty.
> 46:      * Print out the locales.

If you combine two tests into a single one, I'd put the corresponding bug id into the method description.

test/jdk/java/util/Locale/AvailableLocalesTest.java line 61:

> 59:      */
> 60:     @Test
> 61:     public void StreamEqualsArrayTest() {

Method names should start with a lowercase character

test/jdk/java/util/Locale/CaseCheckVariant.java line 50:

> 48:     @ParameterizedTest
> 49:     @MethodSource("variants")
> 50:     public void variantNormalizationTest(String variant) {

"Normalization" -> "Case"? Locale does not normalize the variant.

test/jdk/java/util/Locale/GetInstanceCheck.java line 79:

> 77:         } catch (InvocationTargetException | IllegalAccessException exc) {
> 78:             Throwable cause = exc.getCause();
> 79:             if (exc.getCause() instanceof NullPointerException) {

Should this condition only be meaningful for `InvocationTargetException`?

test/jdk/java/util/Locale/GetInstanceCheck.java line 99:

> 97:         } catch (InvocationTargetException | IllegalAccessException exc) {
> 98:             Throwable cause = exc.getCause();
> 99:             if (cause instanceof NullPointerException) {

Same as above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238910004
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238912059
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238915580
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238927882
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238927101

From jlu at openjdk.org  Thu Jun 22 19:31:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 19:31:54 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v3]
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <gzx5pI7yecjkcBsdlnMywoZ0XjUt3izZC_-YQv4SZNs=.fa300a44-723b-4996-b2c8-ce2a341f0879@github.com>

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

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

 - Method signature is too long
 - Exceptions in GetInstanceCheck.java are distinct, catch clause should be reserved for the underlying exception
 - Rename method to be more clear in CaseCheckVariant.java
 - Method name case in AvailableLocalesTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14609/files
  - new: https://git.openjdk.org/jdk/pull/14609/files/63256db3..c84b3ea0

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

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

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

From jlu at openjdk.org  Thu Jun 22 19:32:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 19:32:00 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v3]
In-Reply-To: <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
 <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>
Message-ID: <bMq3eb2s4qHWSLb8HYplxQnZdKZo1istK0kVFKfWy4w=.5c6c7363-c406-43b7-98f6-704cdf1bdb15@github.com>

On Thu, 22 Jun 2023 18:47:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Method signature is too long
>>  - Exceptions in GetInstanceCheck.java are distinct, catch clause should be reserved for the underlying exception
>>  - Rename method to be more clear in CaseCheckVariant.java
>>  - Method name case in AvailableLocalesTest.java
>
> test/jdk/java/util/Locale/AvailableLocalesTest.java line 46:
> 
>> 44:     /**
>> 45:      * Test that Locale.getAvailableLocales() is non-empty.
>> 46:      * Print out the locales.
> 
> If you combine two tests into a single one, I'd put the corresponding bug id into the method description.

Unless I am mistaken, both bug IDs, 4122700 8282319 are in the combined file.

> test/jdk/java/util/Locale/AvailableLocalesTest.java line 61:
> 
>> 59:      */
>> 60:     @Test
>> 61:     public void StreamEqualsArrayTest() {
> 
> Method names should start with a lowercase character

Missed that, thank you.

> test/jdk/java/util/Locale/CaseCheckVariant.java line 50:
> 
>> 48:     @ParameterizedTest
>> 49:     @MethodSource("variants")
>> 50:     public void variantNormalizationTest(String variant) {
> 
> "Normalization" -> "Case"? Locale does not normalize the variant.

That's a better name, fixed.

> test/jdk/java/util/Locale/GetInstanceCheck.java line 79:
> 
>> 77:         } catch (InvocationTargetException | IllegalAccessException exc) {
>> 78:             Throwable cause = exc.getCause();
>> 79:             if (exc.getCause() instanceof NullPointerException) {
> 
> Should this condition only be meaningful for `InvocationTargetException`?

Yes you're right, that's a good point. Reserved the catch clause to handle `InvocationTargetException` and moved `IllegalAccessException` to the method signature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238940849
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238940976
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238941073
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238942899

From naoto at openjdk.org  Thu Jun 22 20:05:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Jun 2023 20:05:03 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v3]
In-Reply-To: <bMq3eb2s4qHWSLb8HYplxQnZdKZo1istK0kVFKfWy4w=.5c6c7363-c406-43b7-98f6-704cdf1bdb15@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
 <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>
 <bMq3eb2s4qHWSLb8HYplxQnZdKZo1istK0kVFKfWy4w=.5c6c7363-c406-43b7-98f6-704cdf1bdb15@github.com>
Message-ID: <Ssd7DqSXJd_RAMSz7dKRZvYjQwFUw-RzJCAaQGLiQTE=.cb210d3a-00b7-4c89-82c3-8a328b7137d6@github.com>

On Thu, 22 Jun 2023 19:23:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/util/Locale/AvailableLocalesTest.java line 46:
>> 
>>> 44:     /**
>>> 45:      * Test that Locale.getAvailableLocales() is non-empty.
>>> 46:      * Print out the locales.
>> 
>> If you combine two tests into a single one, I'd put the corresponding bug id into the method description.
>
> Unless I am mistaken, both bug IDs, 4122700 8282319 are in the combined file.

Yes. I wanted to make it clear that this `nonEmptyLocalesTest` was for the issue 4122700.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238975301

From jlu at openjdk.org  Thu Jun 22 20:41:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 20:41:33 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v4]
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <n1c2unCuic0dyggqsYeHb2dpZqke-pzTsbnheAtt48c=.1b0ca0a9-ccb1-4f25-8df4-3b13472cac79@github.com>

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

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

  Put Bug ID in method description of nonEmptyLocalesTest()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14609/files
  - new: https://git.openjdk.org/jdk/pull/14609/files/c84b3ea0..ce80e777

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

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

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

From jlu at openjdk.org  Thu Jun 22 20:41:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 20:41:33 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v4]
In-Reply-To: <Ssd7DqSXJd_RAMSz7dKRZvYjQwFUw-RzJCAaQGLiQTE=.cb210d3a-00b7-4c89-82c3-8a328b7137d6@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
 <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>
 <bMq3eb2s4qHWSLb8HYplxQnZdKZo1istK0kVFKfWy4w=.5c6c7363-c406-43b7-98f6-704cdf1bdb15@github.com>
 <Ssd7DqSXJd_RAMSz7dKRZvYjQwFUw-RzJCAaQGLiQTE=.cb210d3a-00b7-4c89-82c3-8a328b7137d6@github.com>
Message-ID: <x1TPZBsvyYoJHEO26oW_MEHSpk_nhflKyxOa46Abv8Q=.d4e9a9db-ad89-4e39-91b3-e9973e68994c@github.com>

On Thu, 22 Jun 2023 20:02:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Unless I am mistaken, both bug IDs, 4122700 8282319 are in the combined file.
>
> Yes. I wanted to make it clear that this `nonEmptyLocalesTest` was for the issue 4122700.

Sorry, I totally misread you said 'method'. Fixed `nonEmptyLocalesTest` to include the bug ID.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1239007083

From naoto at openjdk.org  Thu Jun 22 20:44:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Jun 2023 20:44:05 GMT
Subject: <i18n dev> RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash
Message-ID: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>

Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.

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

Commit messages:
 - 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash

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

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

From rriggs at openjdk.org  Thu Jun 22 20:54:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 20:54:03 GMT
Subject: <i18n dev> RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash
In-Reply-To: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
Message-ID: <arE-d-B5YAOu6rX3a2dM3dnbnQhW_xnEXTOh6zJjiTo=.8fe3a13c-546a-4b94-87dc-cfed898897cd@github.com>

On Thu, 22 Jun 2023 20:36:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.

Correcting the description of the delimiter seems like the best solution.

As a doc-only change it would also be appropriate for JDK 21 also.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1493979047
PR Comment: https://git.openjdk.org/jdk/pull/14620#issuecomment-1603298580

From naoto at openjdk.org  Thu Jun 22 21:36:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Jun 2023 21:36:04 GMT
Subject: <i18n dev> RFR: 8310234: Refactor Locale tests to use JUnit [v4]
In-Reply-To: <n1c2unCuic0dyggqsYeHb2dpZqke-pzTsbnheAtt48c=.1b0ca0a9-ccb1-4f25-8df4-3b13472cac79@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <n1c2unCuic0dyggqsYeHb2dpZqke-pzTsbnheAtt48c=.1b0ca0a9-ccb1-4f25-8df4-3b13472cac79@github.com>
Message-ID: <52hTkD0Tw2c4zRPGgU02Jy_TL0seWHgxhO9rgzWZbdc=.749579d4-edd4-4407-8063-bf09f5cc81dd@github.com>

On Thu, 22 Jun 2023 20:41:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
>> 
>> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
>> 
>> Below is a list of all the changes,
>> 
>> - Refactor Bug4316602.java as LocaleConstructors.java
>> - Refactor Bug4210525.java as CaseCheckVariant.java
>> - Refactor bug6277243.java as RootLocale.java
>> - Refactor bug6312358.java as GetInstanceCheck.java
>> - Refactor Bug8154797.java as CompareProviderFormats.java
>> - Refactor Bug8004240.java as GetAdapterPreference.java
>> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put Bug ID in method description of nonEmptyLocalesTest()

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14609#pullrequestreview-1494026613

From stsypanov at openjdk.org  Fri Jun 23 08:51:06 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 23 Jun 2023 08:51:06 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <SnvjgmShwG_mldT46T2pbzUHESEVOItrlCfpe9zpHKk=.904c54e8-2f2f-4d2f-ba04-2e386ebea260@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Any review?

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

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1603947605

From prappo at openjdk.org  Fri Jun 23 10:46:24 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 10:46:24 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Coincidentally, I'm looking at modernizing some of the equals methods in java.base.

src/java.base/share/classes/java/util/ResourceBundle.java line 743:

> 741:                 return ((module != null) && (module.equals(otherEntry.getModule())) &&
> 742:                         (caller != null) && (caller.equals(otherEntry.getCallerModule())));
> 743:             } catch (NullPointerException | ClassCastException e) {

Are we sure that NPE can only be thrown when calling equals on `name` or `locale` and not, for example, from `getModule()` or `getCallerModule()`?

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

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1494905419
PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1239665426

From stsypanov at openjdk.org  Fri Jun 23 13:49:09 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 23 Jun 2023 13:49:09 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
Message-ID: <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>

On Fri, 23 Jun 2023 10:41:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore logic
>
> src/java.base/share/classes/java/util/ResourceBundle.java line 743:
> 
>> 741:                 return ((module != null) && (module.equals(otherEntry.getModule())) &&
>> 742:                         (caller != null) && (caller.equals(otherEntry.getCallerModule())));
>> 743:             } catch (NullPointerException | ClassCastException e) {
> 
> Are we sure that NPE can only be thrown when calling equals on `name` or `locale` and not, for example, from `getModule()` or `getCallerModule()`?

Yes:

CacheKey(String baseName, Locale locale, Module module, Module caller) {
    Objects.requireNonNull(module);
    Objects.requireNonNull(caller);

    this.name = baseName;
    this.locale = locale;
    this.moduleRef = new KeyElementReference<>(module, referenceQueue, this);
    this.callerRef = new KeyElementReference<>(caller, referenceQueue, this);
    this.modulesHash = module.hashCode() ^ caller.hashCode();
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1239839973

From prappo at openjdk.org  Fri Jun 23 15:15:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 15:15:11 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
 <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>
Message-ID: <XmsdAzRaKH9B131ovAKAAbdRpQb12vp_IQQrZKj1gbk=.cfae6480-1a57-4d3a-9055-c48830db1279@github.com>

On Fri, 23 Jun 2023 13:46:04 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ResourceBundle.java line 743:
>> 
>>> 741:                 return ((module != null) && (module.equals(otherEntry.getModule())) &&
>>> 742:                         (caller != null) && (caller.equals(otherEntry.getCallerModule())));
>>> 743:             } catch (NullPointerException | ClassCastException e) {
>> 
>> Are we sure that NPE can only be thrown when calling equals on `name` or `locale` and not, for example, from `getModule()` or `getCallerModule()`?
>
> Yes:
> 
> CacheKey(String baseName, Locale locale, Module module, Module caller) {
>     Objects.requireNonNull(module);
>     Objects.requireNonNull(caller);
> 
>     this.name = baseName;
>     this.locale = locale;
>     this.moduleRef = new KeyElementReference<>(module, referenceQueue, this);
>     this.callerRef = new KeyElementReference<>(caller, referenceQueue, this);
>     this.modulesHash = module.hashCode() ^ caller.hashCode();
> }

I'll run our CI, and if all good, I'll approve this PR. If nothing else, this change seems reasonable and correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1239940961

From naoto at openjdk.org  Fri Jun 23 17:08:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Jun 2023 17:08:12 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <XmsdAzRaKH9B131ovAKAAbdRpQb12vp_IQQrZKj1gbk=.cfae6480-1a57-4d3a-9055-c48830db1279@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
 <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>
 <XmsdAzRaKH9B131ovAKAAbdRpQb12vp_IQQrZKj1gbk=.cfae6480-1a57-4d3a-9055-c48830db1279@github.com>
Message-ID: <IpzjmCSAYxfa8TjZKuq8vSil9zD4AwrQttpMDlMzOLk=.30818f2b-57e4-4185-b4d5-c1f7493943a1@github.com>

On Fri, 23 Jun 2023 15:11:47 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Yes:
>> 
>> CacheKey(String baseName, Locale locale, Module module, Module caller) {
>>     Objects.requireNonNull(module);
>>     Objects.requireNonNull(caller);
>> 
>>     this.name = baseName;
>>     this.locale = locale;
>>     this.moduleRef = new KeyElementReference<>(module, referenceQueue, this);
>>     this.callerRef = new KeyElementReference<>(caller, referenceQueue, this);
>>     this.modulesHash = module.hashCode() ^ caller.hashCode();
>> }
>
> I'll run our CI, and if all good, I'll approve this PR. If nothing else, this change seems reasonable and correct.

Thanks Pavel for jumping in. I too think this change looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1240055000

From prappo at openjdk.org  Fri Jun 23 20:22:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 20:22:15 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <IpzjmCSAYxfa8TjZKuq8vSil9zD4AwrQttpMDlMzOLk=.30818f2b-57e4-4185-b4d5-c1f7493943a1@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
 <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>
 <XmsdAzRaKH9B131ovAKAAbdRpQb12vp_IQQrZKj1gbk=.cfae6480-1a57-4d3a-9055-c48830db1279@github.com>
 <IpzjmCSAYxfa8TjZKuq8vSil9zD4AwrQttpMDlMzOLk=.30818f2b-57e4-4185-b4d5-c1f7493943a1@github.com>
Message-ID: <xbDWlLVUjAEN5NAUBbZzrqfegkuXsDqV2X8HYjZg3Uc=.b28506b0-2fcb-4f2b-b6a9-d9720dac0718@github.com>

On Fri, 23 Jun 2023 17:05:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I'll run our CI, and if all good, I'll approve this PR. If nothing else, this change seems reasonable and correct.
>
> Thanks Pavel for jumping in. I too think this change looks good.

Yep; all good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1240336318

From prappo at openjdk.org  Fri Jun 23 20:22:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 20:22:13 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <XFf532ACWGl8SAwAfGa7syCi1T44Qsrwd-fFtpOwK08=.305c1c0c-0740-48f7-9577-662c51a35dd7@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Looks good; thanks.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1495944192

From naoto at openjdk.org  Fri Jun 23 20:44:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Jun 2023 20:44:13 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <fvB7deef3tBtzIjFzbEqQpfKtxqvNKIc0QtEOQZtMM8=.fe768c0d-289e-4e03-803c-f25e70a94639@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1495986139

From jlu at openjdk.org  Fri Jun 23 21:37:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 Jun 2023 21:37:17 GMT
Subject: <i18n dev> Integrated: 8310234: Refactor Locale tests to use JUnit
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <EfFl9PdT_ELvd2ULCsyCADkIe7rHTX_AQeUstd820dI=.573fae3a-dbff-4e78-bacb-b0b770ef289a@github.com>

On Thu, 22 Jun 2023 01:08:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

This pull request has now been integrated.

Changeset: dad7bd9e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dad7bd9efc7ca2c245f7e35267479670f93a53a8
Stats:     1112 lines in 15 files changed: 605 ins; 507 del; 0 mod

8310234: Refactor Locale tests to use JUnit

Reviewed-by: naoto

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

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

From prappo at openjdk.org  Fri Jun 23 22:05:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 22:05:14 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <vTFTcMG1igLICIfS79Xz7lvNVFd_cOtp6GW7IQxz0wk=.979a4c3f-dcc1-4292-af4c-dd5ece653b43@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

src/java.base/share/classes/sun/util/resources/Bundles.java line 510:

> 508:                     return false;
> 509:                 }
> 510:                 return Objects.equals(locale, otherEntry.locale)

While the proposal is not wrong, you might want to consider reverting the change to those two lines: 511 and 512. The reason being is that neither `locale` nor `name` can be null, if I understand this class correctly. 

NPE was seemingly caught to cover for `other` being null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1240442051

From prappo at openjdk.org  Fri Jun 23 22:05:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 22:05:15 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <vTFTcMG1igLICIfS79Xz7lvNVFd_cOtp6GW7IQxz0wk=.979a4c3f-dcc1-4292-af4c-dd5ece653b43@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <vTFTcMG1igLICIfS79Xz7lvNVFd_cOtp6GW7IQxz0wk=.979a4c3f-dcc1-4292-af4c-dd5ece653b43@github.com>
Message-ID: <OszskTdC-PTWw0zp9-wl6gzTQuPYaG1sYlO2AWQFKew=.70b5ea1c-312b-4289-b98d-e4dcba7769c6@github.com>

On Fri, 23 Jun 2023 21:59:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> NPE was seemingly caught to cover for other being null.

Unlike that of other file in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1240446275

From vsitnikov at openjdk.org  Sat Jun 24 06:51:16 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 24 Jun 2023 06:51:16 GMT
Subject: <i18n dev> RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files [v2]
In-Reply-To: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
Message-ID: <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>

On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
>> 
>> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
>> 
>> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
>> 
>> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
>> 
>> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into properties-eol-clean-safe
>  - 8298047: Remove all non-significant trailing whitespace from properties files

I've posted the suggetion to add .editorconfig on ide-support-dev, however, the list does not seem to be active: https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

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

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1605290913

From stsypanov at openjdk.org  Sun Jun 25 18:17:31 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 25 Jun 2023 18:17:31 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v4]
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - 8301492: Revert
 - Merge branch 'master' into bundles
 - Restore logic
 - Fix logic
 - Copyright year update
 - Modernize Bubldes.equals()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12328/files
  - new: https://git.openjdk.org/jdk/pull/12328/files/2b07e47e..e304cfe7

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

  Stats: 1043296 lines in 10517 files changed: 730181 ins; 218415 del; 94700 mod
  Patch: https://git.openjdk.org/jdk/pull/12328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12328/head:pull/12328

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

From stsypanov at openjdk.org  Sun Jun 25 18:17:31 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 25 Jun 2023 18:17:31 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <OszskTdC-PTWw0zp9-wl6gzTQuPYaG1sYlO2AWQFKew=.70b5ea1c-312b-4289-b98d-e4dcba7769c6@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <vTFTcMG1igLICIfS79Xz7lvNVFd_cOtp6GW7IQxz0wk=.979a4c3f-dcc1-4292-af4c-dd5ece653b43@github.com>
 <OszskTdC-PTWw0zp9-wl6gzTQuPYaG1sYlO2AWQFKew=.70b5ea1c-312b-4289-b98d-e4dcba7769c6@github.com>
Message-ID: <3f2oJ0MGQmTpvMaZIoPO8l2ByJgWqj7SE3YexxWSKTU=.59883f2b-f13e-4732-9c7b-3a19aff36e67@github.com>

On Fri, 23 Jun 2023 22:02:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/resources/Bundles.java line 510:
>> 
>>> 508:                     return false;
>>> 509:                 }
>>> 510:                 return Objects.equals(locale, otherEntry.locale)
>> 
>> While the proposal is not wrong, you might want to consider reverting the change to those two lines: 511 and 512. The reason being is that neither `locale` nor `name` can be null, if I understand this class correctly. 
>> 
>> NPE was seemingly caught to cover for `other` being null.
>
>> NPE was seemingly caught to cover for other being null.
> 
> Unlike that of other file in this PR.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1241256825

From prappo at openjdk.org  Sun Jun 25 18:45:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Sun, 25 Jun 2023 18:45:15 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v4]
In-Reply-To: <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
Message-ID: <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>

On Sun, 25 Jun 2023 18:17:31 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - 8301492: Revert
>  - Merge branch 'master' into bundles
>  - Restore logic
>  - Fix logic
>  - Copyright year update
>  - Modernize Bubldes.equals()

I'll re-run our CI, and if all good, I'll sponsor this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1606214132

From prappo at openjdk.org  Sun Jun 25 22:35:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Sun, 25 Jun 2023 22:35:07 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v4]
In-Reply-To: <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
 <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>
Message-ID: <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>

On Sun, 25 Jun 2023 18:42:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I'll re-run our CI, and if all good, I'll sponsor this PR.

The CI tests I started have just passed. While this PR is already good, I wonder if we make it even better.

I doubt highly that we need null-checks for CacheKey's name and locale. My suspicion comes from these two facts:

* CacheKey's hashCode calls methods on these fields without checking them for null, and
* CacheKey instances are queried and stored in ConcurrentHashMap, which certainly uses both `equals` and `hashCode`

So, what I'm saying is that if those fields were null, there would be unhandled NPE somewhere; but I cannot see such NPE.  Additionally, those fields are used in toString(). Furthermore, locale is known to not be null because the only place from where it is passed to a CacheKey consturctor is ResourceBundle.getBundleImpl(Module, Module, String, Locale, ResourceBundle.Control), which explicitly checks that locale for not being null.

Does it make sense?

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

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1606291015

From stsypanov at openjdk.org  Mon Jun 26 07:07:08 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 26 Jun 2023 07:07:08 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v4]
In-Reply-To: <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
 <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>
 <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>
Message-ID: <pmUBg2WVYPSlGg3RhUwUv_b-yU_ucRn2KQ5FxpTxHLc=.c01b721e-deec-40c2-98d4-9e39de57ed0f@github.com>

On Sun, 25 Jun 2023 22:32:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'll re-run our CI, and if all good, I'll sponsor this PR.
>
>> I'll re-run our CI, and if all good, I'll sponsor this PR.
> 
> The CI tests I started have just passed. While this PR is already good, I wonder if we make it even better.
> 
> I doubt highly that we need null-checks for CacheKey's name and locale. My suspicion comes from these two facts:
> 
> * CacheKey's hashCode calls methods on these fields without checking them for null, and
> * CacheKey instances are queried and stored in ConcurrentHashMap, which certainly uses both `equals` and `hashCode`
> 
> So, what I'm saying is that if those fields were null, there would be unhandled NPE somewhere; but I cannot see such NPE.  Additionally, those fields are used in toString(). Furthermore, locale is known to not be null because the only place from where it is passed to a CacheKey consturctor is ResourceBundle.getBundleImpl(Module, Module, String, Locale, ResourceBundle.Control), which explicitly checks that locale for not being null.
> 
> Does it make sense?

@pavelrappo you mean we can revert changes to ResourceBundle.java in lines 729 and 733?

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

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1606832885

From prappo at openjdk.org  Mon Jun 26 09:24:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 09:24:12 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v4]
In-Reply-To: <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
 <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>
 <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>
Message-ID: <SD0KiFCK5z1o_F7uEeGxSE4g9gGE69sI3J9d5tgQY3Q=.8229aa98-1e80-4305-aa78-0d76842d4a37@github.com>

On Sun, 25 Jun 2023 22:32:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'll re-run our CI, and if all good, I'll sponsor this PR.
>
>> I'll re-run our CI, and if all good, I'll sponsor this PR.
> 
> The CI tests I started have just passed. While this PR is already good, I wonder if we make it even better.
> 
> I doubt highly that we need null-checks for CacheKey's name and locale. My suspicion comes from these two facts:
> 
> * CacheKey's hashCode calls methods on these fields without checking them for null, and
> * CacheKey instances are queried and stored in ConcurrentHashMap, which certainly uses both `equals` and `hashCode`
> 
> So, what I'm saying is that if those fields were null, there would be unhandled NPE somewhere; but I cannot see such NPE.  Additionally, those fields are used in toString(). Furthermore, locale is known to not be null because the only place from where it is passed to a CacheKey consturctor is ResourceBundle.getBundleImpl(Module, Module, String, Locale, ResourceBundle.Control), which explicitly checks that locale for not being null.
> 
> Does it make sense?

> @pavelrappo you mean we can revert changes to ResourceBundle.java in lines 729 and 733?

Yes, those lines. We can revert to x.equals(otherEntry.x).

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

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1607062302

From erikj at openjdk.org  Mon Jun 26 09:32:19 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Jun 2023 09:32:19 GMT
Subject: <i18n dev> RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files [v2]
In-Reply-To: <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>
Message-ID: <G2HH46a1taYMgOcec5NyuO8VdM0f22Km2LRV5HkEAqg=.dd217011-3a2d-4357-ba0e-bf46f725822a@github.com>

On Sat, 24 Jun 2023 06:47:48 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

> I've posted the suggetion to add .editorconfig on ide-support-dev, however, the list does not seem to be active: https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

I think that sounds like a reasonable idea. I'm not following that mailing list. I think you can just post a PR with your suggested contents and target build-dev (through the `build` label). I'm not familiar with this kind of file, so an explanation of which IDEs support it would be good to include.

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

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1607073914

From stsypanov at openjdk.org  Mon Jun 26 09:46:08 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 26 Jun 2023 09:46:08 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v5]
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8301492: Revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12328/files
  - new: https://git.openjdk.org/jdk/pull/12328/files/e304cfe7..28f0e270

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

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

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

From prappo at openjdk.org  Mon Jun 26 11:21:10 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 11:21:10 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v5]
In-Reply-To: <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>
Message-ID: <tZVsNpdIIExL_-1ZuTLBWEIo0mSPqDHUXPFW0P36nYU=.1bd8f165-2878-405c-9515-b2905c72b2fe@github.com>

On Mon, 26 Jun 2023 09:46:08 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301492: Revert

Thanks, the fix now looks good and simple; testing.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1498284842

From naoto at openjdk.org  Mon Jun 26 17:02:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jun 2023 17:02:12 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v5]
In-Reply-To: <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>
Message-ID: <N_UJNuThH3Ccndsmbut0tM4l75q2fmwkdHep1NOfZl0=.63bed739-143a-40c4-9432-10ea6b020834@github.com>

On Mon, 26 Jun 2023 09:46:08 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301492: Revert

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1498996353

From prappo at openjdk.org  Mon Jun 26 18:02:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 18:02:13 GMT
Subject: <i18n dev> RFR: 8310890: Normalize identifier names
Message-ID: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>

Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.

Also, this PR fixes a few related typos.

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

Commit messages:
 - Improve further
 - Initial commit

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

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

From naoto at openjdk.org  Mon Jun 26 18:15:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jun 2023 18:15:03 GMT
Subject: <i18n dev> RFR: 8310890: Normalize identifier names
In-Reply-To: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
Message-ID: <7gkL2YRq3AiwC62ppD-ZcdJD6KIqSh0jJKaLHXuOaR0=.46b62a7b-a334-485b-897a-c752c58a881c@github.com>

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
> 
> Also, this PR fixes a few related typos.

Looks fine to me

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14653#pullrequestreview-1499124651

From rriggs at openjdk.org  Mon Jun 26 18:25:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 18:25:03 GMT
Subject: <i18n dev> RFR: 8310890: Normalize identifier names
In-Reply-To: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
Message-ID: <n-PTCkbhnAgSlgnp5ceEqtttihoysxfSj0zBs2nNlZI=.1cfb44b7-2ac0-455f-875b-4dbf149e11f9@github.com>

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
> 
> Also, this PR fixes a few related typos.

Looks good, with or without the suggestion.

src/java.base/share/classes/java/util/EnumMap.java line 690:

> 688:             Object otherValue = em.vals[i];
> 689:             if (otherValue != ourValue &&
> 690:                 (otherValue == null || !otherValue.equals(ourValue)))

Is this the same as java.util.Objects:  
  `!Objects.equals(vals[i], em.vals[i]);`

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14653#pullrequestreview-1499137712
PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242585695

From duke at openjdk.org  Mon Jun 26 18:34:07 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Mon, 26 Jun 2023 18:34:07 GMT
Subject: <i18n dev> RFR: 8310890: Normalize identifier names
In-Reply-To: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
Message-ID: <QV9dS8UG0P8m8Krb2liDi-97z2VSxhM7MU7tpXjJcDY=.1e5d769f-b219-4a1f-9d07-afb29ff52793@github.com>

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
> 
> Also, this PR fixes a few related typos.

make/data/charsetmapping/charsets line 149:

> 147:     package sun.nio.cs
> 148:     type    sbcs
> 149:     histname ISO8859_2

Should this column be re-aligned with the longer name?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242595069

From prappo at openjdk.org  Mon Jun 26 18:41:06 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 18:41:06 GMT
Subject: <i18n dev> RFR: 8310890: Normalize identifier names
In-Reply-To: <n-PTCkbhnAgSlgnp5ceEqtttihoysxfSj0zBs2nNlZI=.1cfb44b7-2ac0-455f-875b-4dbf149e11f9@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
 <n-PTCkbhnAgSlgnp5ceEqtttihoysxfSj0zBs2nNlZI=.1cfb44b7-2ac0-455f-875b-4dbf149e11f9@github.com>
Message-ID: <Qk6uNgHT6GqAohSQBgJYkjNp77K4__vTrow6idqQ89o=.4f0b2408-ce32-4f1d-91fb-e328c1ba7d1d@github.com>

On Mon, 26 Jun 2023 18:21:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
>> 
>> Also, this PR fixes a few related typos.
>
> src/java.base/share/classes/java/util/EnumMap.java line 690:
> 
>> 688:             Object otherValue = em.vals[i];
>> 689:             if (otherValue != ourValue &&
>> 690:                 (otherValue == null || !otherValue.equals(ourValue)))
> 
> Is this the same as java.util.Objects:  
>   `!Objects.equals(vals[i], em.vals[i]);`

You are right: we can fold this if-else construct into that utility method. That said, it in *this* PR, I'd prefer not to.

The reason is that I've been preparing a much bigger PR that uses Objects.equals as well as other utility methods and modern language features to improve some equals, hashCode, and compareTo implementations across java.base. I'm planning to publish that PR soon. In fact, this change to Java variable names was cherry-picked from that bigger PR, to separate trivial renames from code changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242608041

From prappo at openjdk.org  Mon Jun 26 18:47:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 18:47:05 GMT
Subject: <i18n dev> RFR: 8310890: Normalize identifier names
In-Reply-To: <QV9dS8UG0P8m8Krb2liDi-97z2VSxhM7MU7tpXjJcDY=.1e5d769f-b219-4a1f-9d07-afb29ff52793@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
 <QV9dS8UG0P8m8Krb2liDi-97z2VSxhM7MU7tpXjJcDY=.1e5d769f-b219-4a1f-9d07-afb29ff52793@github.com>
Message-ID: <SAjhx4th-mMHrLFybNA4wfm-CyJKv-hJox8lULAMmFk=.a31ea21b-40f1-4855-b2e8-4b20c9a871ea@github.com>

On Mon, 26 Jun 2023 18:31:06 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
>> 
>> Also, this PR fixes a few related typos.
>
> make/data/charsetmapping/charsets line 149:
> 
>> 147:     package sun.nio.cs
>> 148:     type    sbcs
>> 149:     histname ISO8859_2
> 
> Should this column be re-aligned with the longer name?

I thought about it before publishing the PR. I decided not to re-align anything because (i) the change would be bigger and (ii) the fact that there was already a property that is similarly misaligned; search for:

    internal true

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242617579

From prappo at openjdk.org  Mon Jun 26 18:58:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 18:58:03 GMT
Subject: <i18n dev> RFR: 8310890: Normalize identifier names
In-Reply-To: <SAjhx4th-mMHrLFybNA4wfm-CyJKv-hJox8lULAMmFk=.a31ea21b-40f1-4855-b2e8-4b20c9a871ea@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
 <QV9dS8UG0P8m8Krb2liDi-97z2VSxhM7MU7tpXjJcDY=.1e5d769f-b219-4a1f-9d07-afb29ff52793@github.com>
 <SAjhx4th-mMHrLFybNA4wfm-CyJKv-hJox8lULAMmFk=.a31ea21b-40f1-4855-b2e8-4b20c9a871ea@github.com>
Message-ID: <KAH4dSHp8umZJ8rfYehG7hlDJYVUTeCfJtZErbIXPyI=.8216967e-a1aa-45ec-bcd6-67cd1bd6457a@github.com>

On Mon, 26 Jun 2023 18:44:42 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> make/data/charsetmapping/charsets line 149:
>> 
>>> 147:     package sun.nio.cs
>>> 148:     type    sbcs
>>> 149:     histname ISO8859_2
>> 
>> Should this column be re-aligned with the longer name?
>
> I thought about it before publishing the PR. I decided not to re-align anything because (i) the change would be bigger and (ii) the fact that there was already a property that is similarly misaligned; search for:
> 
>     internal true

If you are concerned with functionality rather than looks, then I can tell you this:

1. The build succeeds and tier1 tests pass.
2. The code that parses that file expect one or more whitespace characters as a separator:

        String[] tokens = line.split("\\s+");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242629052

From stsypanov at openjdk.org  Mon Jun 26 19:45:16 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 26 Jun 2023 19:45:16 GMT
Subject: <i18n dev> Integrated: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <tOgE-FVvX6lj2iE1DCaQ6cMEtLlkN_DUQQGTysHw4V4=.37f0af57-16fe-4435-93a0-1b7d2b0b3317@github.com>

On Tue, 31 Jan 2023 11:40:43 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

This pull request has now been integrated.

Changeset: 297c7996
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/297c7996311e1e29d4a82fc8ffc7ad322e8ef107
Stats:     7 lines in 2 files changed: 0 ins; 4 del; 3 mod

8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey

Reviewed-by: prappo, naoto

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

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

From naoto at openjdk.org  Tue Jun 27 03:39:30 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 03:39:30 GMT
Subject: <i18n dev> RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash [v2]
In-Reply-To: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
Message-ID: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>

> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting a review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14620/files
  - new: https://git.openjdk.org/jdk/pull/14620/files/f105d13a..76182881

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

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

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

From darcy at openjdk.org  Tue Jun 27 03:52:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 03:52:03 GMT
Subject: <i18n dev> RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash [v2]
In-Reply-To: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
 <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
Message-ID: <4GjeSZT6JGVJhAW1-RR6FUqjg5-nN9SCFrbzDzWCfu4=.2b3867c4-3b6a-4c1b-b59b-496ee485e23d@github.com>

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting a review comment

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1499892443

From iris at openjdk.org  Tue Jun 27 05:08:03 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 27 Jun 2023 05:08:03 GMT
Subject: <i18n dev> RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash [v2]
In-Reply-To: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
 <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
Message-ID: <pSc_Q0Eed2-juY2P_cmHhxwXnG5GSH-5xxX3LfZQ7gY=.45464b92-ca84-402b-8b5d-7efabf2b9761@github.com>

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting a review comment

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1499946634

From lancea at openjdk.org  Tue Jun 27 10:28:07 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Jun 2023 10:28:07 GMT
Subject: <i18n dev> RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash [v2]
In-Reply-To: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
 <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
Message-ID: <iVcZPHPYFpGQ132mB0aohicr4EQ-4WrlundjdVdgPiQ=.65b6bca6-1378-4a31-bbd5-3ea7afa64a9f@github.com>

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting a review comment

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1500501347

From rriggs at openjdk.org  Tue Jun 27 13:33:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 13:33:06 GMT
Subject: <i18n dev> RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash [v2]
In-Reply-To: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
 <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
Message-ID: <RPrdirzz4k3VrjyvCJfXTUM7TORD7_BsP9p7AjLjvjQ=.8e8bb8a7-f94c-4212-9310-69e7a0efc684@github.com>

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting a review comment

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1500879927

From prappo at openjdk.org  Tue Jun 27 15:50:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 27 Jun 2023 15:50:12 GMT
Subject: <i18n dev> Integrated: 8310890: Normalize identifier names
In-Reply-To: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
Message-ID: <uoHYcMykyT9Mv0pCEqNuWEANMTDSeW50sVORz_5K5Bk=.e94c8df7-fd55-44c8-9bdb-50995f7786fa@github.com>

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
> 
> Also, this PR fixes a few related typos.

This pull request has now been integrated.

Changeset: f6133edb
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6133edb08dd7a7d764638c5b1cdd5c3e56ed64e
Stats:     184 lines in 10 files changed: 0 ins; 0 del; 184 mod

8310890: Normalize identifier names

Reviewed-by: naoto, rriggs

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

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

From naoto at openjdk.org  Tue Jun 27 16:16:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 16:16:21 GMT
Subject: <i18n dev> Integrated: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash
In-Reply-To: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
Message-ID: <1DFD5JYAwbovHYyJKqOcLdWArPdyS12YNPdWsl0T44Y=.99b0a09c-38eb-40ef-9750-f7bf2388288c@github.com>

On Thu, 22 Jun 2023 20:36:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.

This pull request has now been integrated.

Changeset: ec45bd64
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash

Reviewed-by: rriggs, darcy, iris, lancea

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

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

From naoto at openjdk.org  Tue Jun 27 17:15:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 17:15:10 GMT
Subject: <i18n dev> [jdk21] RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash
Message-ID: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>

Hi all,

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

The commit being backported was authored by Naoto Sato on 27 Jun 2023 and was reviewed by Roger Riggs, Joe Darcy, Iris Clark and Lance Andersen.

Thanks!

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

Commit messages:
 - Backport ec45bd64d504d579aef54c924fb8ca75a944036f

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

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

From rriggs at openjdk.org  Tue Jun 27 17:47:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 17:47:10 GMT
Subject: <i18n dev> [jdk21] RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash
In-Reply-To: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>
References: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>
Message-ID: <C6Nzks8AYjHxUu3DHFBuXhaXInFjC_TijGfyu24QVs0=.2d619f28-1dbc-455e-968f-b3227dbf9077@github.com>

On Tue, 27 Jun 2023 17:07:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ec45bd64](https://github.com/openjdk/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 27 Jun 2023 and was reviewed by Roger Riggs, Joe Darcy, Iris Clark and Lance Andersen.
> 
> Thanks!

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/70#pullrequestreview-1501531725

From naoto at openjdk.org  Tue Jun 27 18:10:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 18:10:05 GMT
Subject: <i18n dev> [jdk21] Integrated: 8310182: DateTimeFormatter date
 formats (ISO_LOCAL_DATE) separated with hyphen, not dash
In-Reply-To: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>
References: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>
Message-ID: <7uJJ466Na_MqizqkWWwUvxJSDKdDUEQXKLgPe9tiEmY=.10a177dd-5bc8-441b-a89b-b8d4494ce203@github.com>

On Tue, 27 Jun 2023 17:07:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ec45bd64](https://github.com/openjdk/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 27 Jun 2023 and was reviewed by Roger Riggs, Joe Darcy, Iris Clark and Lance Andersen.
> 
> Thanks!

This pull request has now been integrated.

Changeset: df26258d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/df26258d80ece4a836f873660adbf1f69a3b684b
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash

Reviewed-by: rriggs
Backport-of: ec45bd64d504d579aef54c924fb8ca75a944036f

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

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

From jlu at openjdk.org  Tue Jun 27 23:04:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 Jun 2023 23:04:17 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
Message-ID: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>

Please review this PR which refactors the majority of Currency tests to use JUnit. (The leftover will be done in a separate PR).

The largest change is in `CurrencyTest.java`. To maintain the grouping of similar tests, JUnit nested classes were used.

I also believe that `Bug4512215.java` should probably be merged into `CurrencyTest.java` (since they both test getCurrencyCode() and getDefaultFractionDigits().

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

Commit messages:
 - Remove trailing WS in Bug4512215.java
 - Rename Bug6807534.java as CurrencyNameProviderTest.java
 - Refactor CurrencyTest.java
 - Clarify CheckDataVersion.java
 - Refactor Bug8154295.java
 - Refactor Bug6807534.java
 - Refactor Bug4512215.java

Changes: https://git.openjdk.org/jdk/pull/14682/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310923
  Stats: 613 lines in 6 files changed: 261 ins; 184 del; 168 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

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

From duke at openjdk.org  Wed Jun 28 07:47:18 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 28 Jun 2023 07:47:18 GMT
Subject: <i18n dev> Withdrawn: 8289220: Locale.forLanguageTag throws NPE due
 to soft ref used in locale cache being cleared
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <a9tIGyZRcY3g5hVcTTnTDAKn-i7p0Fr2zYZ2teEYIjI=.b6c2e027-17ae-4925-8b19-f9f66755314f@github.com>

On Tue, 30 May 2023 08:31:08 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

This pull request has been closed without being integrated.

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

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

From stsypanov at openjdk.org  Wed Jun 28 11:13:16 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 28 Jun 2023 11:13:16 GMT
Subject: <i18n dev> RFR: 8311030: ResourceBundle.handleKeySet() is racy
Message-ID: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>

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

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

Commit messages:
 - 8311030: ResourceBundle.handleKeySet() is racy

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

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

From prappo at openjdk.org  Wed Jun 28 14:24:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Jun 2023 14:24:03 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: <ow3S3p8XruamqYsKnafB4kLGPcREhoMNT8ypZEvn5pQ=.0b28cf2d-cf24-46ce-b067-f1b3beae5f66@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.

To put this into perspective, the race you are trying to fix seems benign, so the PR qualifies as a performance improvement, not a bug fix. Is my understanding correct?

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

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

From lkorinth at openjdk.org  Wed Jun 28 17:04:24 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 28 Jun 2023 17:04:24 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source files
Message-ID: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>

Remove trailing "blank" lines in source files.

I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.

The fix removes trailing lines matching ^[[:space:]]*$ in

- *.java
- *.cpp
- *.hpp
- *.c
- *.h 

I have applied the following bash script to each file:

    file="$1"
    
    while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
        truncate -s -1 "$file"
    done

`git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
`git diff --ignore-blank-lines  master` displays one change

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

Commit messages:
 - h
 - c
 - hpp
 - cpp
 - 8311043: Remove trailing blank lines in source files

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

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

From stsypanov at openjdk.org  Wed Jun 28 18:53:55 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 28 Jun 2023 18:53:55 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: <IMdmNXo_4UMT6o3QtJt6abq-20S8DpBYunZ3iV8aFl0=.7f5a96fe-7b98-4161-a407-5b3d74577d87@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.

It'd be a benign race in case all members of `HashSet` are `final`, but they aren't, so there are no safe publication guarantees.

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

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

From rriggs at openjdk.org  Wed Jun 28 20:05:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 Jun 2023 20:05:54 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: <1zA3pC1c0MINzje9OrP7pTcuM8td7-iS63LFMa-eXhQ=.8e58fbab-739e-4359-adc0-9e9de96dc0ab@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.

Looks ok; was this a tool detected race?

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14692#pullrequestreview-1503889426

From naoto at openjdk.org  Wed Jun 28 20:23:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 Jun 2023 20:23:54 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: <u4sem03Y7DOtH4M6BTiCNFdw1umudZ2DuMAvhlPZkQA=.e6cb35d8-d1e8-445b-bada-f2df5f2ac119@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.

+1

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14692#pullrequestreview-1503927831

From jlu at openjdk.org  Wed Jun 28 20:27:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 Jun 2023 20:27:28 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v2]
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: <NQYItq5p7CEaF7S1IR7B8jn2ehTYxYVRwlQM-0sgXTs=.1cbbdc16-9d2a-499c-9c47-06118551e2a4@github.com>

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

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

 - Rename Bug4512215.java as MinorUndefinedCodes.java and update goal of test file
 - Refactor and improve ValidateISO4217.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/2d6ed5a7..bff5cc6c

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

  Stats: 496 lines in 3 files changed: 178 ins; 199 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

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

From prappo at openjdk.org  Wed Jun 28 20:32:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Jun 2023 20:32:53 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: <knF664yGNDuITQrtjJhNL39BT2I8O0EKq00TBcHyOdk=.8ed64435-04c2-4703-bbf9-60f6834a8d1b@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.

While I still cannot see any malignancy in that race, the proposed change makes the code simpler to reason about and probably faster to execute. Also, the change does not seem to introduce new bugs.

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

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

From jlu at openjdk.org  Wed Jun 28 20:34:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 Jun 2023 20:34:30 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v3]
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: <gjVX4xVkkclEu4u-3yLMbazqSsCY67d9ovLhp9xJmgI=.e14d348a-f168-43fb-bdb5-2b8e70c69953@github.com>

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

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

 - Rename Bug8154295.java as NumCodeAsStringTest.java
 - Re-include the data version check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/bff5cc6c..3975c57f

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

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

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

From jlu at openjdk.org  Wed Jun 28 20:49:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 Jun 2023 20:49:18 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v4]
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: <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>

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

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

  Remove unusued JUnit imports from ValidateISO4217.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/3975c57f..10d54167

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

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

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

From erikj at openjdk.org  Thu Jun 29 07:23:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 07:23:54 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <nuJPc-yjOE7DrniF-EEjhLk-HQOBXJs4Ju4rWV4xxpw=.29e0f50a-084f-4091-8d96-ef05ab41427b@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14698#pullrequestreview-1504702261

From dholmes at openjdk.org  Thu Jun 29 07:43:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 07:43:58 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

It also seems far too large and disruptive.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612567676

From erikj at openjdk.org  Thu Jun 29 08:00:58 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 08:00:58 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <Jo4ev4ByTzxMNpDvKGyYL9G8TzbpVerc1YXde4iu_5Q=.afe5e6d2-63a5-4956-9d5c-17675789a051@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

The patch is leaving exactly one newline at the end of the file.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612588091

From lkorinth at openjdk.org  Thu Jun 29 08:58:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 08:58:59 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <z1LaNlMKfruphxc495xDHe2Ou64psUrXMobtiqqnqqk=.cdf515c9-2243-42ba-bea6-d24967ce3634@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.
>
> It also seems far too large and disruptive.

Do you still think it is too disruptive after Erik's explanation?  I could split it in more reviews, but I thought that maybe it would just make the review harder. I was hoping the two `git diff` commands I gave in my first comment in combination with the clean script would make the change seem reviewable.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612660457

From stsypanov at openjdk.org  Thu Jun 29 10:10:53 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 29 Jun 2023 10:10:53 GMT
Subject: <i18n dev> RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <1zA3pC1c0MINzje9OrP7pTcuM8td7-iS63LFMa-eXhQ=.8e58fbab-739e-4359-adc0-9e9de96dc0ab@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
 <1zA3pC1c0MINzje9OrP7pTcuM8td7-iS63LFMa-eXhQ=.8e58fbab-739e-4359-adc0-9e9de96dc0ab@github.com>
Message-ID: <XM0KGQy4UjkPbdXTCg1ij0awIv4TDSMWa51Fuub4wnc=.d8b68f8b-0842-44b4-a405-10394b501451@github.com>

On Wed, 28 Jun 2023 20:02:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Double-checked locking should rely on local variable to avoid racy reads from volatile field.
>
> Looks ok; was this a tool detected race?

@RogerRiggs no tool, just fell into the sources while debugging my application

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

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

From coleenp at openjdk.org  Thu Jun 29 12:03:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:03:56 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Why do we care about this?

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613018234

From dholmes at openjdk.org  Thu Jun 29 12:14:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 12:14:55 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

But to me this is too disruptive with no tangible benefit. And you need buy-in from all the different areas affected by this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613043398

From dholmes at openjdk.org  Thu Jun 29 12:21:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 12:21:55 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: <9CkadtQawvo0NV_vgNtYSNRXiKak6vr9NgGMejHnjzs=.1ece2c0e-63ce-4008-975d-183f15aeb710@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 see any race here. The addition of the local serves no purpose AFAICS - we don't even save any volatile reads.

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

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

From rgiulietti at openjdk.org  Thu Jun 29 12:27:54 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Jun 2023 12:27:54 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: <3Df73YJmudWZSS5ZVu7Ty5MpVuVj49z30FTQwfntADY=.2d5354c4-0d0a-4c83-a938-9f8f1fb83500@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.

The role of the local `keySet` seems pretty useless. It doesn't save neither volatile reads nor writes.

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

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

From duke at openjdk.org  Thu Jun 29 12:27:55 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 29 Jun 2023 12:27:55 GMT
Subject: <i18n dev> RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <XM0KGQy4UjkPbdXTCg1ij0awIv4TDSMWa51Fuub4wnc=.d8b68f8b-0842-44b4-a405-10394b501451@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
 <1zA3pC1c0MINzje9OrP7pTcuM8td7-iS63LFMa-eXhQ=.8e58fbab-739e-4359-adc0-9e9de96dc0ab@github.com>
 <XM0KGQy4UjkPbdXTCg1ij0awIv4TDSMWa51Fuub4wnc=.d8b68f8b-0842-44b4-a405-10394b501451@github.com>
Message-ID: <iK0qc3U5ZqTX1eDPzJe_YvQqiOtwfRttf0ZgZIIpgy4=.83179d33-0083-48b5-94f8-e482fb9b9ddc@github.com>

On Thu, 29 Jun 2023 10:08:27 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Looks ok; was this a tool detected race?
>
> @RogerRiggs no tool, just fell into the sources while debugging my application

@stsypanov I don't see that there's any issue with the existing code as the volatile field is only written at most once as guarded by the synchronized-block. Best case this patch avoids an extra volatile read (presuming it isn't optimized away).

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

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

From lkorinth at openjdk.org  Thu Jun 29 12:38:57 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 12:38:57 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
Message-ID: <vkPgWAbLJRXEPOQ0alkrWJ7Gv7jLDEF3ak1ipe9xxZw=.5b93f57d-7ddb-42fb-b41b-76f4e3193d78@github.com>

On Thu, 29 Jun 2023 12:01:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Why do we care about this?

I care because of global-whitespace-cleanup-mode (in emacs). It helps me remove trailing whitespaces and blanklines when saving but it will not fix a file that was "dirty" when it was opened. Trailing blank lines triggers it not to clean whitespaces for me.

And it does not look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613095390

From coleenp at openjdk.org  Thu Jun 29 12:42:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:42:56 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

You could fix your emacs functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613106245

From lkorinth at openjdk.org  Thu Jun 29 13:08:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 13:08:59 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
Message-ID: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>

On Thu, 29 Jun 2023 12:11:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

My changes look like this in the diff output

 }
-

Removal of the last newline would look like this:

-}
+}
\ No newline at end of file

(both with `git diff` and `git diff --unified`) 

I have not tested if this is also true for the generated webrevs, but I think that is precisely how they are created.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613152641

From dfuchs at openjdk.org  Thu Jun 29 13:17:59 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jun 2023 13:17:59 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: <CBJBV1pHp_p1jvuPhoQfC9_Cdx3CzBKdMOyWsS9_31I=.45795ee2-9937-40c6-876f-440865ede9b9@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.

The new code makes it more visible that 1. keySet is expected to be volatile and 2. that there is no path were code could be reordered leading to the 'wrong' value of keySet being returned. So maybe there's no race, but the new code make it more obvious.

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

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

From rriggs at openjdk.org  Thu Jun 29 13:58:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Jun 2023 13:58:55 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: <65iOV8kCbGeb64W8nBn41INqfaz3Lz8gkMf01Z5ChRA=.10c44948-8594-4676-a937-60f39bf4350d@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.

Given all the comments, I don't think this is ready to integrate.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14692#pullrequestreview-1505356736

From lkorinth at openjdk.org  Thu Jun 29 14:12:55 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 14:12:55 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
Message-ID: <pfRQFPE48dsB4zX-Rf7hnkzlyMzdctcY-veiO1KeN70=.bffbbead-ef44-461c-8362-21418c7db00e@github.com>

On Thu, 29 Jun 2023 12:40:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> You could fix your emacs functions.

It is a *very nice* feature of global-whitespace-cleanup-mode

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613252347

From shade at openjdk.org  Thu Jun 29 14:42:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 Jun 2023 14:42:54 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: <A7ktTadqMkvN346a252Bq7Yf7V0tMsUE8yLGPpu5u28=.3ca18a93-c68b-4ee4-b399-26bced2b9265@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.

Yeah, current code looks like a correct volatile-bearing-DCL. `keySet` is safely published already. Introducing local variable gains us nothing here performance-wise. Arguably, readability is worse. So I would avoid doing this change.

We could have explored if we could drop `volatile` from `keySet`, but it does not look safe, given `HashMap` is not safely constructed.

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

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

From coleenp at openjdk.org  Thu Jun 29 15:46:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 15:46:57 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <DR0fysIfEikX8EG5J7RlPyej6GFMsw-_WkeuS7pM6HM=.36fca2c0-54a4-4563-b40a-c626bc7e1587@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Per had an emacs feature to remove whitespaces at the end of the line, and gave me the vim version of that.  That's a nice feature.  I object to this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613437709

From naoto at openjdk.org  Thu Jun 29 16:12:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 16:12:55 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: <TKEKvdWZ8MAezAqTh_TbKmYUzd8gqMUqOyoJ74kLgSY=.a539b2cb-83fb-4caa-b846-f4fa8a3131bb@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.

Retrieving the approval, per the discussion.

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

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14692#pullrequestreview-1505656637

From lkorinth at openjdk.org  Thu Jun 29 16:55:05 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:05 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <azIQJToZ2tpGJTsICHpL96zs9mmHI3fW-laYwy3H-Xk=.99615245-24f9-4b95-b66d-eaba04c8318c@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This was not liked, I will close it.

I will possibly do it under another PR for the GC code.

Thanks for reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613526703

From lkorinth at openjdk.org  Thu Jun 29 16:55:06 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:06 GMT
Subject: <i18n dev> Withdrawn: 8311043: Remove trailing blank lines in
 source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <Hsf1WhdMKL5I-3HmOkCZQJWI3MPIHPnFUpo_oMkZj6I=.1ca1f233-3eb8-4d1e-ae3e-eb19729dc1c9@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This pull request has been closed without being integrated.

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

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

From jlu at openjdk.org  Thu Jun 29 18:17:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 Jun 2023 18:17:52 GMT
Subject: <i18n dev> RFR: 6960866: [Fmt-Ch] ChoiceFormat claims impossible
 and unimplemented functionality
Message-ID: <c5Tn7PWZHbcxFWiTotcm9K-08xyu0ctxbuhvgFxIzXE=.af1dbece-46ad-4ce0-9437-d225e898a7a7@github.com>

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.

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

Commit messages:
 - Remove impossible claim from param description

Changes: https://git.openjdk.org/jdk/pull/14715/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14715&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/jdk/pull/14715.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14715/head:pull/14715

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

From naoto at openjdk.org  Thu Jun 29 19:28:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 19:28:05 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v4]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>

> 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/8c52462a...870ec1fe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/ac6ea421..870ec1fe

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

  Stats: 39769 lines in 1438 files changed: 16937 ins; 14906 del; 7926 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

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

From stsypanov at openjdk.org  Thu Jun 29 21:01:56 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 29 Jun 2023 21:01:56 GMT
Subject: <i18n dev> RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <3Df73YJmudWZSS5ZVu7Ty5MpVuVj49z30FTQwfntADY=.2d5354c4-0d0a-4c83-a938-9f8f1fb83500@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
 <3Df73YJmudWZSS5ZVu7Ty5MpVuVj49z30FTQwfntADY=.2d5354c4-0d0a-4c83-a938-9f8f1fb83500@github.com>
Message-ID: <8ki_yyK89OWdwbkkcvs1iliT2PLt0PdYTOyHxIwwR3Y=.3005151e-0f5c-465f-907f-0d433b5e8903@github.com>

On Thu, 29 Jun 2023 12:23:11 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Double-checked locking should rely on local variable to avoid racy reads from volatile field.
>
> The role of the local `keySet` seems pretty useless. It doesn't save neither volatile reads nor writes.

@rgiulietti `keySet` is volatile, so providing it has already been initialized, in original code we read from it twice when doing null-check and returning the value. With local variable we read from the field only once, don't we?

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

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

From naoto at openjdk.org  Thu Jun 29 22:33:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 22:33:53 GMT
Subject: <i18n dev> RFR: 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: <JLk4I_a_BpP66jaIRexKZoVBAVxEeOaLZMzfp8tqzP4=.ee844411-2e9a-4623-a986-d51ec1a3553f@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.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14715#pullrequestreview-1506215477

From naoto at openjdk.org  Thu Jun 29 23:36:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 23:36:01 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v4]
In-Reply-To: <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
Message-ID: <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>

On Wed, 28 Jun 2023 20:49:18 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.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unusued JUnit imports from ValidateISO4217.java

test/jdk/java/util/Currency/CurrencyNameProviderTest.java line 43:

> 41: import static org.junit.jupiter.api.Assertions.assertThrows;
> 42: 
> 43: public class CurrencyNameProviderTest {

Since this is not a generic CurrencyNameProvider test, but specific to the default impl of CNP.getDisplayName(), the class name could be more specific.

test/jdk/java/util/Currency/CurrencyTest.java line 81:

> 79:         }
> 80: 
> 81:         // Calling getInstance() with an illegal name should throw an IAE

illegal name -> invalid currency code

test/jdk/java/util/Currency/CurrencyTest.java line 241:

> 239:                 Arguments.of("JOD", 3), Arguments.of("KWD", 3),
> 240:                 Arguments.of("LYD", 3), Arguments.of("OMR", 3),
> 241:                 Arguments.of("TND", 3), Arguments.of("TRL", 0), // Turkish Lira

The turkish lira comment should apply to both TRL and TRY

test/jdk/java/util/Currency/CurrencyTest.java line 321:

> 319:         Currency currency2 = Currency.getInstance(currencyCode);
> 320:         assertEquals(currency1, currency2, "Didn't get same instance for same currency code");
> 321:         assertEquals(currency1.getCurrencyCode(), currencyCode, "Currency code changed");

Error message more like "wrong currency code", than "changed"

test/jdk/java/util/Currency/MinorUndefinedCodes.java line 27:

> 25:  * @test
> 26:  * @bug 4512215 4818420 4819436 8310923
> 27:  * @summary Test some minor undefined currencies.

It'd be more readable something like "currencies without minor units." The class name can also be renamed to something like NoMinorUnitCurrenciesTest

test/jdk/java/util/Currency/ValidateISO4217.java line 82:

> 80:     // Codes derived from ISO4217 golden-data file
> 81:     private static final List<Arguments> ISO4217Codes = new ArrayList<Arguments>();
> 82:     // Additional codes not from the ISO4217 golden-data file

Are these from the golden file?

test/jdk/java/util/Currency/ValidateISO4217.java line 96:

> 94:         setUpISO4217Codes();
> 95:         setUpAdditionalCodes();
> 96:         finishTestCurrencies();

The method name `finish` is kind of confusing. I'd explicitly describe what the method does, i.e, setup `other` currencies.

test/jdk/java/util/Currency/ValidateISO4217.java line 192:

> 190:                 /* Defined neither in ISO 4217 nor ISO 3166 list */
> 191:                 {"XK", "EUR", "978", "2"},      // Kosovo
> 192:         };

I'd prefer this array to be placed as static in the class, not within the method.

test/jdk/java/util/Currency/ValidateISO4217.java line 214:

> 212:                         + "PTE-ROL-RUR-SDD-SIT-SLL-SKK-SRG-STD-TMM-TPE-TRL-VEF-UYI-USN-USS-VEB-VED-"
> 213:                         + "XAG-XAU-XBA-XBB-XBC-XBD-XDR-XFO-XFU-XPD-XPT-XSU-XTS-XUA-XXX-"
> 214:                         + "YUM-ZMK-ZWD-ZWN-ZWR";

Ditto as `extraCodes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247234295
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247239767
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247238613
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247237567
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247247681
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247255026
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247253772
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247254253
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247254528

From dholmes at openjdk.org  Fri Jun 30 01:24:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 01:24:05 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
 <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
Message-ID: <ufj18ITz-S_VgkscmrxacxLtfQB-4I5hpgs8c61kOmA=.15f34364-70ac-4279-8669-f01e109b8411@github.com>

On Thu, 29 Jun 2023 13:05:58 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My changes look like this in the diff output
> ```
>  }
> -
> ```

Thanks for showing  this and other output. To me this looked like the final newline had been removed. I would have expected to see something that more obviously showed more than one blank line before hand and exactly one after.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613985636

From jlu at openjdk.org  Fri Jun 30 07:40:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 07:40:01 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v4]
In-Reply-To: <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
 <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
Message-ID: <7qATYdYxzCqo0JpV8_YJv25vsM3ZaQ9eHZFhhu3b6sA=.78d55a95-1420-4d85-aeb8-a16ee4f34f3b@github.com>

On Thu, 29 Jun 2023 23:24:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unusued JUnit imports from ValidateISO4217.java
>
> test/jdk/java/util/Currency/ValidateISO4217.java line 82:
> 
>> 80:     // Codes derived from ISO4217 golden-data file
>> 81:     private static final List<Arguments> ISO4217Codes = new ArrayList<Arguments>();
>> 82:     // Additional codes not from the ISO4217 golden-data file
> 
> Are these from the golden file?

Unless I am misinterpreting the question, `additionalCodes` is built from the `extraCodes` array, which contains data that is not found in tablea1.txt(golden file)

> test/jdk/java/util/Currency/ValidateISO4217.java line 96:
> 
>> 94:         setUpISO4217Codes();
>> 95:         setUpAdditionalCodes();
>> 96:         finishTestCurrencies();
> 
> The method name `finish` is kind of confusing. I'd explicitly describe what the method does, i.e, setup `other` currencies.

Renamed it to your suggestion

> test/jdk/java/util/Currency/ValidateISO4217.java line 192:
> 
>> 190:                 /* Defined neither in ISO 4217 nor ISO 3166 list */
>> 191:                 {"XK", "EUR", "978", "2"},      // Kosovo
>> 192:         };
> 
> I'd prefer this array to be placed as static in the class, not within the method.

Fixed, as well as for `otherCodes`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247539421
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247540723
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247540191

From jlu at openjdk.org  Fri Jun 30 07:43:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 07:43:58 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v4]
In-Reply-To: <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
 <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
Message-ID: <TBqm2x3szEGY2wveCjdCAFn7DqqIeTCUwZitXGPH--U=.c8530a36-ab5f-4d46-a873-29ec41b3284b@github.com>

On Thu, 29 Jun 2023 22:38:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unusued JUnit imports from ValidateISO4217.java
>
> test/jdk/java/util/Currency/CurrencyNameProviderTest.java line 43:
> 
>> 41: import static org.junit.jupiter.api.Assertions.assertThrows;
>> 42: 
>> 43: public class CurrencyNameProviderTest {
> 
> Since this is not a generic CurrencyNameProvider test, but specific to the default impl of CNP.getDisplayName(), the class name could be more specific.

I have renamed the file to be more descriptive, but if acronyms are not preferred in file names, I can rename it.

> test/jdk/java/util/Currency/CurrencyTest.java line 241:
> 
>> 239:                 Arguments.of("JOD", 3), Arguments.of("KWD", 3),
>> 240:                 Arguments.of("LYD", 3), Arguments.of("OMR", 3),
>> 241:                 Arguments.of("TND", 3), Arguments.of("TRL", 0), // Turkish Lira
> 
> The turkish lira comment should apply to both TRL and TRY

Yes good point, I have clarified the comment

> test/jdk/java/util/Currency/CurrencyTest.java line 321:
> 
>> 319:         Currency currency2 = Currency.getInstance(currencyCode);
>> 320:         assertEquals(currency1, currency2, "Didn't get same instance for same currency code");
>> 321:         assertEquals(currency1.getCurrencyCode(), currencyCode, "Currency code changed");
> 
> Error message more like "wrong currency code", than "changed"

Updated the err msg

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247544121
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247544370
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247544313

From jlu at openjdk.org  Fri Jun 30 07:50:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 07:50:50 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v5]
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: <UqOz1g9rUo_Oju1onM43XnqrFbHC20VfC4lvB2rG5jg=.835ae9bd-6ff2-41d2-84bf-b19ac249279b@github.com>

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

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

 - Further clarification regarding minor undefined currencies
 - Review: Rename MinorUndefinedCodes.java to NoMinorUnitCurrenciesTest.java
 - Review: Update ValidateISO4217.java
 - Review: Rename CurrencyNameProviderTest to be more specific
 - Review: CurrencyTest updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/10d54167..ba3d2e5d

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

  Stats: 196 lines in 5 files changed: 96 ins; 92 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

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

From jlu at openjdk.org  Fri Jun 30 07:50:53 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 07:50:53 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v4]
In-Reply-To: <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
 <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
Message-ID: <-paG45Ag2Vp53ajYgHdCIch8XdlNMf1oUpQniPqY5Sg=.b4061ca8-da4d-4fbb-96f7-2283784d8317@github.com>

On Thu, 29 Jun 2023 23:07:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unusued JUnit imports from ValidateISO4217.java
>
> test/jdk/java/util/Currency/MinorUndefinedCodes.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 4512215 4818420 4819436 8310923
>> 27:  * @summary Test some minor undefined currencies.
> 
> It'd be more readable something like "currencies without minor units." The class name can also be renamed to something like NoMinorUnitCurrenciesTest

Adjusted the wording throughout the file according to your suggestions

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247547152

From jlu at openjdk.org  Fri Jun 30 08:01:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 08:01:14 GMT
Subject: <i18n dev> RFR: 8310818: Refactor more Locale tests to use JUnit
Message-ID: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@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

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

Commit messages:
 - Rename Bug8032842.java to PreserveTagCase.java
 - Refactor Bug8032842.java to use JUnit
 - Rename Bug8071929.java as ISO3166.java
 - Refactor Bug8071929.java to use JUnit
 - Rename Bug8026766.java as LRToString.java
 - Refactor Bug8026766.java to use JUnit
 - Merge branch 'master' into MoreLocaleToJUnit
 - Rename Bug4175998Test.java as ISO639.java
 - Refactor Bug4175998Test.java to use JUnit
 - Add comment on outdated status
 - ... and 5 more: https://git.openjdk.org/jdk/compare/7db2f087...f065726e

Changes: https://git.openjdk.org/jdk/pull/14721/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14721&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310818
  Stats: 1350 lines in 12 files changed: 696 ins; 625 del; 29 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 rgiulietti at openjdk.org  Fri Jun 30 08:34:01 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 30 Jun 2023 08:34:01 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: <4uRnV_Kb5Amn1lPhPLUikeJwoCMJFGZkpLJsAlGncAI=.d43b18a3-210b-455d-bc4c-1a7bfb43a089@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.

True. I was mislead because the return statement does not appear in the changeset (the line is textually the same, although it has a different semantics: `keySet` now refers to a local), so I didn't count for it.

In the end, this PR is not about fixing a race, as the title seems to suggest (the original code is correct), but to avoid a volatile read, right?

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

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

From stsypanov at openjdk.org  Fri Jun 30 10:27:55 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 30 Jun 2023 10:27:55 GMT
Subject: <i18n dev> RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <4uRnV_Kb5Amn1lPhPLUikeJwoCMJFGZkpLJsAlGncAI=.d43b18a3-210b-455d-bc4c-1a7bfb43a089@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
 <4uRnV_Kb5Amn1lPhPLUikeJwoCMJFGZkpLJsAlGncAI=.d43b18a3-210b-455d-bc4c-1a7bfb43a089@github.com>
Message-ID: <twvqnxD71-3aSBZEiggLyWXEsMHaOdAx8zfvEPKeY8s=.965caa69-5f20-4608-9580-f42860b86980@github.com>

On Fri, 30 Jun 2023 08:30:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> In the end, this PR is not about fixing a race, as the title seems to suggest (the original code is correct), but to avoid a volatile read, right?

Yeah, probably I was wrong in my conclusion. Should I rename the ticket?

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

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

From dcubed at openjdk.org  Fri Jun 30 15:21:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 15:21:10 GMT
Subject: <i18n dev> RFR: 8311043: Remove trailing blank lines in source
 files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <1HPsLLkrre-aTNkUCrJ2Os1Ba20NZW-s3bYL1nJU17Q=.47ea0d5b-f382-48a5-ba1b-957a003277d6@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Ending the file with a blank line? I would not have expected that at all.
I expect a single EOL at the end of the file; from a visual POV, the last
line of non-blank text ends with an EOL. No more, no less.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1614806396

From naoto at openjdk.org  Fri Jun 30 16:27:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Jun 2023 16:27:56 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v5]
In-Reply-To: <UqOz1g9rUo_Oju1onM43XnqrFbHC20VfC4lvB2rG5jg=.835ae9bd-6ff2-41d2-84bf-b19ac249279b@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <UqOz1g9rUo_Oju1onM43XnqrFbHC20VfC4lvB2rG5jg=.835ae9bd-6ff2-41d2-84bf-b19ac249279b@github.com>
Message-ID: <tjJnXGZZThGFPWMIsUrNaZbb4ZUyUQAEXvtClfJdBqM=.1a7775cc-2b85-4af0-a857-761a3c9dc0e1@github.com>

On Fri, 30 Jun 2023 07:50:50 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.
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Further clarification regarding minor undefined currencies
>  - Review: Rename MinorUndefinedCodes.java to NoMinorUnitCurrenciesTest.java
>  - Review: Update ValidateISO4217.java
>  - Review: Rename CurrencyNameProviderTest to be more specific
>  - Review: CurrencyTest updates

test/jdk/java/util/Currency/CurrencyTest.java line 243:

> 241:                 // Old and New Turkish Lira
> 242:                 Arguments.of("TRL", 0), Arguments.of("TRY", 2),
> 243:                 Arguments.of("TND", 3)

Probably `TND` moving upward before the comment would be clearer, like:

                Arguments.of("LYD", 3), Arguments.of("OMR", 3),
                Arguments.of("TND", 3),

                // Old and New Turkish Lira
                Arguments.of("TRL", 0), Arguments.of("TRY", 2)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1248059699

From jlu at openjdk.org  Fri Jun 30 16:49:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 16:49:22 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v6]
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: <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>

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

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

  Review: Adjust data provider regarding Turkish Lira

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/ba3d2e5d..0ada95ed

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

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

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

From jlu at openjdk.org  Fri Jun 30 16:49:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 16:49:22 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v5]
In-Reply-To: <tjJnXGZZThGFPWMIsUrNaZbb4ZUyUQAEXvtClfJdBqM=.1a7775cc-2b85-4af0-a857-761a3c9dc0e1@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <UqOz1g9rUo_Oju1onM43XnqrFbHC20VfC4lvB2rG5jg=.835ae9bd-6ff2-41d2-84bf-b19ac249279b@github.com>
 <tjJnXGZZThGFPWMIsUrNaZbb4ZUyUQAEXvtClfJdBqM=.1a7775cc-2b85-4af0-a857-761a3c9dc0e1@github.com>
Message-ID: <cQvVUIwoOIU3GT4nXGzE3NaP0n15J-KJfx0MI-DzRCk=.b7e5db2c-c776-46f0-9d00-240512dd6c2b@github.com>

On Fri, 30 Jun 2023 16:22:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Further clarification regarding minor undefined currencies
>>  - Review: Rename MinorUndefinedCodes.java to NoMinorUnitCurrenciesTest.java
>>  - Review: Update ValidateISO4217.java
>>  - Review: Rename CurrencyNameProviderTest to be more specific
>>  - Review: CurrencyTest updates
>
> test/jdk/java/util/Currency/CurrencyTest.java line 243:
> 
>> 241:                 // Old and New Turkish Lira
>> 242:                 Arguments.of("TRL", 0), Arguments.of("TRY", 2),
>> 243:                 Arguments.of("TND", 3)
> 
> Probably `TND` moving upward before the comment would be clearer, like:
> 
>                 Arguments.of("LYD", 3), Arguments.of("OMR", 3),
>                 Arguments.of("TND", 3),
> 
>                 // Old and New Turkish Lira
>                 Arguments.of("TRL", 0), Arguments.of("TRY", 2)

Adjusted `TND` upwards

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1248079845

From naoto at openjdk.org  Fri Jun 30 16:54:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Jun 2023 16:54:57 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v6]
In-Reply-To: <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>
Message-ID: <pJ2Q3h6pQuW1C5IMJqJCxJ-TMHEoef97nZJIEe2shsk=.937aebc2-23fa-4f37-9d48-6507b1d97fd3@github.com>

On Fri, 30 Jun 2023 16:49:22 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.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Adjust data provider regarding Turkish Lira

LGTM. Thanks for the refactoring

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14682#pullrequestreview-1507553074

From lancea at openjdk.org  Fri Jun 30 17:13:55 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Jun 2023 17:13:55 GMT
Subject: <i18n dev> RFR: 8310923: Refactor Currency tests to use JUnit
 [v6]
In-Reply-To: <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>
Message-ID: <f3LMF0nU_RqVmIIDItYPUNL0elTbj8bEWoebZjpFvoI=.523f5038-5ad4-4d39-a366-b4fe58ccd432@github.com>

On Fri, 30 Jun 2023 16:49:22 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.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Adjust data provider regarding Turkish Lira

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14682#pullrequestreview-1507578660