From joehw at openjdk.java.net  Tue Mar  1 01:51:04 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 1 Mar 2022 01:51:04 GMT
Subject: <i18n dev> RFR: 8282081: java.time.DateTimeFormatter: wrong
 definition of symbol F
In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
Message-ID: <nw80UevZwudeu7Htg3wdcpdB42PHxhBabvb-7o6HMH0=.aa095ac1-6620-4f5e-8038-cac05a3df992@github.com>

On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted.

Was the following assessment in the bug report correct?
    "the symbol F in java.time.DateTimeFormatter is no use in any pattern. It just may cause an exception."
    
If true, then it seems the compatibility risk would be low since pattern letter "F" as is currently defined is of no use.

Also, the CSR summary needs to be a summary of the action to be taken, that is, changing the pattern definition. The current statement is similar to the problem statement.

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

PR: https://git.openjdk.java.net/jdk/pull/7640

From naoto at openjdk.java.net  Tue Mar  1 02:29:01 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 1 Mar 2022 02:29:01 GMT
Subject: <i18n dev> RFR: 8282081: java.time.DateTimeFormatter: wrong
 definition of symbol F
In-Reply-To: <nw80UevZwudeu7Htg3wdcpdB42PHxhBabvb-7o6HMH0=.aa095ac1-6620-4f5e-8038-cac05a3df992@github.com>
References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
 <nw80UevZwudeu7Htg3wdcpdB42PHxhBabvb-7o6HMH0=.aa095ac1-6620-4f5e-8038-cac05a3df992@github.com>
Message-ID: <vgaHqe4UsUIBk-Ehv0OMISi1gaW16Ce7xckpgtbuqqs=.5d2b25bc-068d-49b0-b5c2-7e9482cbdc3e@github.com>

On Tue, 1 Mar 2022 01:47:45 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Was the following assessment in the bug report correct? "the symbol F in java.time.DateTimeFormatter is no use in any pattern. It just may cause an exception."

No, not correct. It is currently incorrectly tied with the `ChronoField.ALIGNED_DAY_OF_WEEK_IN_MONTH` field, and works as such.

> If true, then it seems the compatibility risk would be low since pattern letter "F" as is currently defined is of no use.

Thus, the risk should remain `medium`. 

> Also, the CSR summary needs to be a summary of the action to be taken, that is, changing the pattern definition. The current statement is similar to the problem statement.

Thanks, modified.

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

PR: https://git.openjdk.java.net/jdk/pull/7640

From joehw at openjdk.java.net  Tue Mar  1 03:10:10 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 1 Mar 2022 03:10:10 GMT
Subject: <i18n dev> RFR: 8282081: java.time.DateTimeFormatter: wrong
 definition of symbol F
In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
Message-ID: <c50eKPi2RQZ2DO7HS7SxOWyLwBOLRZZlDTVlx45lZhg=.728cee84-abb5-442f-a413-bacb49741c04@github.com>

On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7640

From scolebourne at openjdk.java.net  Tue Mar  1 07:44:24 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Tue, 1 Mar 2022 07:44:24 GMT
Subject: <i18n dev> RFR: 8282081: java.time.DateTimeFormatter: wrong
 definition of symbol F
In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
Message-ID: <mSpS6hyzq9_haO6p_RlFhVK_lTjjoujC2tdTZ3KBnPE=.14c90340-26db-4389-bb23-94e6c086032e@github.com>

On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted.

Although there is incompatibility, I believe a fix is the correct choice. The issue arose because of the poor description of the field in LDML.

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

Marked as reviewed by scolebourne (Author).

PR: https://git.openjdk.java.net/jdk/pull/7640

From lancea at openjdk.java.net  Tue Mar  1 11:26:06 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 1 Mar 2022 11:26:06 GMT
Subject: <i18n dev> RFR: 8282081: java.time.DateTimeFormatter: wrong
 definition of symbol F
In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
Message-ID: <5Qz9140XHsXdewRRvFmblwa2fXvSaWIbxzBHgBbXjiI=.206a3e0d-04cb-4a64-8bd4-db6137ac7b88@github.com>

On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted.

I think the change makes sense.

Are there any TCK tests that need to be modified or Added?  I made a very quick scan of the open/test/jdk/java/time/tck/java/time/ dirs and did not see any tests but of course I could have missed it

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7640

From rriggs at openjdk.java.net  Tue Mar  1 14:44:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 1 Mar 2022 14:44:08 GMT
Subject: <i18n dev> RFR: 8282081: java.time.DateTimeFormatter: wrong
 definition of symbol F
In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
Message-ID: <JrnjP9mJ1l0AaVK1CgaussFZfea3uT650LVgj3pAhrI=.a9f41d49-e1b6-4c9c-9a2a-d78751150dc1@github.com>

On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7640

From naoto at openjdk.java.net  Tue Mar  1 17:53:11 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 1 Mar 2022 17:53:11 GMT
Subject: <i18n dev> RFR: 8282081: java.time.DateTimeFormatter: wrong
 definition of symbol F
In-Reply-To: <5Qz9140XHsXdewRRvFmblwa2fXvSaWIbxzBHgBbXjiI=.206a3e0d-04cb-4a64-8bd4-db6137ac7b88@github.com>
References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
 <5Qz9140XHsXdewRRvFmblwa2fXvSaWIbxzBHgBbXjiI=.206a3e0d-04cb-4a64-8bd4-db6137ac7b88@github.com>
Message-ID: <6v6TAncUWuG62AgTH1Kr4Ip9sGhhtD-1kl3fWfW4eKA=.023fd2eb-93ed-4d8d-94d8-deb5c4328200@github.com>

On Tue, 1 Mar 2022 11:22:35 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Are there any TCK tests that need to be modified or Added? I made a very quick scan of the open/test/jdk/java/time/tck/java/time/ dirs and did not see any tests but of course I could have missed it

There are test cases in the `TCK` directory that only verify its validity, such as number of digits. Those tests pass with this fix.

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

PR: https://git.openjdk.java.net/jdk/pull/7640

From duke at openjdk.java.net  Wed Mar  2 19:16:26 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 2 Mar 2022 19:16:26 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE
 when invoked by JNI code with no caller frame
Message-ID: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>

The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.

The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:

        final ClassLoader loader = (caller != null) ?
                caller.getClassLoader() : getLoader(getCallerModule(caller));

A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.

The javadoc was updated for the caller sensitive methods changed.

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

Commit messages:
 - Use the unnamed module defined to the system class loader instead of the
 - JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame

Changes: https://git.openjdk.java.net/jdk/pull/7663/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280902
  Stats: 265 lines in 4 files changed: 254 ins; 3 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663

From naoto at openjdk.java.net  Wed Mar  2 19:55:13 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 2 Mar 2022 19:55:13 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame
In-Reply-To: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
Message-ID: <o-xaokf-Wr8hJiXx58_MPUeVE2VT3FYdHpgDHVed6T8=.18adc137-ed18-4a2b-94e1-3082226efd00@github.com>

On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
> 
>         final ClassLoader loader = (caller != null) ?
>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Looks good to me. I believe a CSR is needed for this change.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7663

From mchung at openjdk.java.net  Wed Mar  2 20:34:08 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 2 Mar 2022 20:34:08 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame
In-Reply-To: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
Message-ID: <7oA9HtlO1-ONvq9YAJX1GXghSrvk534cGlyRkW0Wa8w=.bbc15ace-7028-4f7c-9386-ee7181fabb9a@github.com>

On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
> 
>         final ClassLoader loader = (caller != null) ?
>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Instead of sprinkling the null caller text in the javadoc in each `getBundle` method, we can specify that that in the class specification, for example, after the "Resource bundles in other modules and class path" section.


In cases where the {@code getBundle} factory method is called from a context 
where there is no caller frame on the stack (e.g. when called directly from
a JNI attached thread), the caller module is default to the unnamed module for the
{@linkplain ClassLoader#getSystemClassLoader system class loader}.


What do you think?

src/java.base/share/classes/java/util/ResourceBundle.java line 1588:

> 1586:                                                 Control control) {
> 1587:         final ClassLoader loader = (caller != null) ?
> 1588:                 caller.getClassLoader() : getLoader(getCallerModule(caller));

Suggestion:

              ClassLoader loader = getLoader(getCallerModule(caller));


This can be simplified as above.  I would drop `final` too as it only adds noise to the code.

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

PR: https://git.openjdk.java.net/jdk/pull/7663

From duke at openjdk.java.net  Wed Mar  2 21:31:58 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 2 Mar 2022 21:31:58 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame [v2]
In-Reply-To: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
Message-ID: <w0w_alna8tBYSYk3JAvzHdMlUW3XO7A4z0dePCya8VU=.23472322-ecd6-44d6-8dde-e93d7239a14b@github.com>

> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
> 
>         final ClassLoader loader = (caller != null) ?
>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/ResourceBundle.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7663/files
  - new: https://git.openjdk.java.net/jdk/pull/7663/files/30778063..9e8fb193

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7663

From duke at openjdk.java.net  Wed Mar  2 21:53:01 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 2 Mar 2022 21:53:01 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame [v3]
In-Reply-To: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
Message-ID: <9edBzfTHw8OYJ7z9605AmBZ5uKfYY_DgayK9YUX_We4=.dd6923be-2a4f-4d9b-a96f-539d43afd4b1@github.com>

> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
> 
>         final ClassLoader loader = (caller != null) ?
>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  suggested changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7663/files
  - new: https://git.openjdk.java.net/jdk/pull/7663/files/9e8fb193..eeb2d0fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=01-02

  Stats: 48 lines in 1 file changed: 6 ins; 41 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663

From mchung at openjdk.java.net  Wed Mar  2 22:44:16 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 2 Mar 2022 22:44:16 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame [v3]
In-Reply-To: <9edBzfTHw8OYJ7z9605AmBZ5uKfYY_DgayK9YUX_We4=.dd6923be-2a4f-4d9b-a96f-539d43afd4b1@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
 <9edBzfTHw8OYJ7z9605AmBZ5uKfYY_DgayK9YUX_We4=.dd6923be-2a4f-4d9b-a96f-539d43afd4b1@github.com>
Message-ID: <t1YZ83Ve__oDejpeA--_JyIjpB9qVcPhaUjtoyvSr2I=.515c58d5-f207-40aa-990b-d3c044fcd29d@github.com>

On Wed, 2 Mar 2022 21:53:01 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
>> 
>> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
>> 
>>         final ClassLoader loader = (caller != null) ?
>>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
>> 
>> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
>> 
>> The javadoc was updated for the caller sensitive methods changed.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

Thanks for the update.

src/java.base/share/classes/java/util/ResourceBundle.java line 1567:

> 1565:      * module will be used.
> 1566:      * @param caller
> 1567:      * @return

Maybe you intended to make this `/* .... */` instead of javadoc?  no need to have `@param` and `@return` for this simple method.

src/java.base/share/classes/java/util/ResourceBundle.java line 2251:

> 2249:     @CallerSensitive
> 2250:     public static final void clearCache() {
> 2251:         final Module callerModule = getCallerModule(Reflection.getCallerClass());

nit: final can be dropped here.

test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/NullCallerResourceBundle.java line 52:

> 50: import java.nio.file.Paths;
> 51: import java.util.Properties;
> 52: import java.util.ResourceBundle;

nit: good to keep the imports in alphabetic order.

test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/NullCallerResourceBundle.java line 74:

> 72: 
> 73:         // set up shared library path
> 74:         final String sharedLibraryPathEnvName = Platform.sharedLibraryPathVariableName();

Nit: `final` adds noise but no other value to the test.  Can consider dropping it.

test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/NullCallerResourceBundle.java line 89:

> 87: 
> 88: 
> 89:     private static void makePropertiesFile() throws IOException {

This can be removed?

test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/exeNullCallerResourceBundle.c line 28:

> 26: 
> 27: #include "jni.h"
> 28: #undef NDEBUG

is this line unintended?

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

PR: https://git.openjdk.java.net/jdk/pull/7663

From psadhukhan at openjdk.java.net  Thu Mar  3 12:33:23 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 3 Mar 2022 12:33:23 GMT
Subject: <i18n dev> RFR: 8282602: Refactor java/awt classes javadoc to use
 @throws instead of @exception
Message-ID: <FVJL0ITAodybntUy2Ro7w5FmBxCQXDhgEZSckEcpW8o=.f25b6a6a-78b4-4c07-90d6-cb506cd73d87@github.com>

Prevailing JDK coding practices use "@throws" rather than "@exception".
Refactor existing java/awt classes javadoc to use @throws

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

Commit messages:
 - Fix
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7675/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7675&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282602
  Stats: 350 lines in 73 files changed: 0 ins; 0 del; 350 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7675.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7675/head:pull/7675

PR: https://git.openjdk.java.net/jdk/pull/7675

From duke at openjdk.java.net  Thu Mar  3 13:55:01 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 3 Mar 2022 13:55:01 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame [v3]
In-Reply-To: <t1YZ83Ve__oDejpeA--_JyIjpB9qVcPhaUjtoyvSr2I=.515c58d5-f207-40aa-990b-d3c044fcd29d@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
 <9edBzfTHw8OYJ7z9605AmBZ5uKfYY_DgayK9YUX_We4=.dd6923be-2a4f-4d9b-a96f-539d43afd4b1@github.com>
 <t1YZ83Ve__oDejpeA--_JyIjpB9qVcPhaUjtoyvSr2I=.515c58d5-f207-40aa-990b-d3c044fcd29d@github.com>
Message-ID: <qvx8G-U6X1hiBYceGqw2pKmh0qiVZFv1uRklf8QPMMg=.ea03689f-3022-47ee-aa6f-2d4c1ac46ae3@github.com>

On Wed, 2 Mar 2022 22:21:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   suggested changes
>
> test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/exeNullCallerResourceBundle.c line 28:
> 
>> 26: 
>> 27: #include "jni.h"
>> 28: #undef NDEBUG
> 
> is this line unintended?

Forcing the assert() seems like a good idea in a test

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

PR: https://git.openjdk.java.net/jdk/pull/7663

From duke at openjdk.java.net  Thu Mar  3 16:55:46 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 3 Mar 2022 16:55:46 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame [v4]
In-Reply-To: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
Message-ID: <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com>

> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
> 
>         final ClassLoader loader = (caller != null) ?
>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  more suggested changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7663/files
  - new: https://git.openjdk.java.net/jdk/pull/7663/files/eeb2d0fa..45f9b37b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=02-03

  Stats: 31 lines in 2 files changed: 2 ins; 13 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663

From naoto at openjdk.java.net  Thu Mar  3 19:40:27 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 3 Mar 2022 19:40:27 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate
Message-ID: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>

Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

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

Commit messages:
 - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

Changes: https://git.openjdk.java.net/jdk/pull/7683/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279185
  Stats: 250 lines in 12 files changed: 216 ins; 0 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From mchung at openjdk.java.net  Thu Mar  3 21:45:04 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 3 Mar 2022 21:45:04 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame [v4]
In-Reply-To: <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
 <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com>
Message-ID: <YFyxt5SKirI5ci3jEchy9MtqWMDHXzJQDgW3Zn8BopA=.15cbdb9e-d956-4fb8-83b5-48a2ca7718e1@github.com>

On Thu, 3 Mar 2022 16:55:46 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
>> 
>> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
>> 
>>         final ClassLoader loader = (caller != null) ?
>>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
>> 
>> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
>> 
>> The javadoc was updated for the caller sensitive methods changed.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more suggested changes

Marked as reviewed by mchung (Reviewer).

src/java.base/share/classes/java/util/ResourceBundle.java line 1570:

> 1568:         Module callerModule = (caller != null) ? caller.getModule()
> 1569:                 : ClassLoader.getSystemClassLoader().getUnnamedModule();
> 1570:         return callerModule;

nit: `callerModule` variable is not needed.  It can simply do:

    return (caller != null) ? caller.getModule()
                            : ClassLoader.getSystemClassLoader().getUnnamedModule();

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

PR: https://git.openjdk.java.net/jdk/pull/7663

From naoto at openjdk.java.net  Fri Mar  4 05:02:37 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 05:02:37 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v2]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <fvSGh0a86O7VEKQn4YA3uro576viuy5nmOXlVExQViM=.510416dc-33fa-4b4b-9a5a-35a08e261d07@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

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

  copyright year fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/28d93903..12c6212a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From duke at openjdk.java.net  Fri Mar  4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Hi

I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
Now: what is the next step?

This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.

ciao
matteo

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From duke at openjdk.java.net  Fri Mar  4 16:56:25 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 16:56:25 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double semicolons
 at the end of lines
Message-ID: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>

Hi

I have reviewed the code for removing double semicolons at the end of lines

all the best
matteo

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

Commit messages:
 - Removed double semicolon at the end of lines

Changes: https://git.openjdk.java.net/jdk/pull/7268/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7268&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282657
  Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7268.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7268/head:pull/7268

PR: https://git.openjdk.java.net/jdk/pull/7268

From jwaters at openjdk.java.net  Fri Mar  4 16:56:26 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Fri, 4 Mar 2022 16:56:26 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <MN1ZlPsviXs5KpzVm8f3tQCJGp4XUZisKCT0Zc5WMVE=.9ef74900-2544-463f-9109-9a59d0e2ea1e@github.com>
Message-ID: <lG5726a2a2WsQQRwKZ-SUq00bw3xlHNvLwgcYapsIY4=.d0ad6d98-14f6-4f55-b06c-fe24dc042505@github.com>

On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> Hi
> 
> I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted.
> Now: what is the next step?
> 
> This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code.
> 
> ciao
> matteo

Hi @matteobaccan

The next step would be to create a relevant issue on the tracker and set it to track this PR. Since you don't have the ability to create new issues on the JBS yet I'll help you create one, please rename your PR title to 8282657 and the system should take care of the rest and automatically mark your PR as ready for review after setting it to track the corresponding JBS entry.

Cheers,
Julian

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From naoto at openjdk.java.net  Fri Mar  4 17:01:07 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 17:01:07 GMT
Subject: <i18n dev> Integrated: 8282081: java.time.DateTimeFormatter: wrong
 definition of symbol F
In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com>
Message-ID: <VFMhvM3R5fFtcfh8jpLXsmRadP7rxpSw3H62SuxBpvI=.5675a9f1-01c2-406a-9650-85fe5a6ee21d@github.com>

On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted.

This pull request has now been integrated.

Changeset: 733c7907
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/733c7907b0059cc734fd1aa5b8d31f9c3e2e3079
Stats:     5 lines in 3 files changed: 0 ins; 0 del; 5 mod

8282081: java.time.DateTimeFormatter: wrong definition of symbol F

Reviewed-by: joehw, scolebourne, lancea, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/7640

From lancea at openjdk.java.net  Fri Mar  4 17:07:59 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Mar 2022 17:07:59 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <e7XmpMjRNztZjXRaLS_7w4v_zyHgRMOWuaP-uvgHc8U=.1fabaeab-3387-4056-8b46-6851ef81c0d3@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

The changes look OK.  The copyright year probably should be updated as part of this PR

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From duke at openjdk.java.net  Fri Mar  4 17:14:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Fri, 4 Mar 2022 17:14:05 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <Z5IUTXYy0jJDvo942sQbkENuPE1poTsr0KXGmlNjK-8=.4b7a9484-d07e-4582-8f09-532018f06875@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Hi Lance

I can make a second commit updating the copyright year

Tell me if this is necessary

ciao
matteo

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From rriggs at openjdk.java.net  Fri Mar  4 17:20:05 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 17:20:05 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain.  The client modules are usually separated out, as are hotspot.
And corresponding tests.
This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
If you had ask ahead of time, I would have suggested finding something with more value.

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

Changes requested by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From ihse at openjdk.java.net  Fri Mar  4 17:50:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Mar 2022 17:50:03 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <UZMe07GwGmxtV0yNEmp8lmvGErijX5P0Gi8vCTMM1eY=.c117f6e6-cd47-4e44-b70f-3e00254e658f@github.com>
Message-ID: <uclpoZxrJsB8HaLQGJ4mOFL-PlE1VkzzSiFYVX9Xu74=.cf93ab56-6689-4c02-aaed-db24b78811b5@github.com>

On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain.  The client modules are usually separated out, as are hotspot.
> And corresponding tests.
> This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers.
> If you had ask ahead of time, I would have suggested finding something with more value.

@RogerRiggs Otoh, this change is really trivial. I have verified that all changes are replacing trailing ";;" in Java code. These are all clearly typos. I think it's nice that we try to strive for a high quality, and while you are correct this is maybe not the most pressing issue, I think it's nice to get a cleanup like this done. 

I'd argue that this is a trivial change. If you are worried, let's get a couple of more reviewers. I can't see the need to split this up per area.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From jlaskey at openjdk.java.net  Fri Mar  4 18:01:25 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 4 Mar 2022 18:01:25 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly
Message-ID: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>

Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 


@Benchmark 
public void bigDecimalDefaultLocale() { 
    result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
} 

@Benchmark 
public void bigDecimalLocaleAlternate() { 
    result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
    other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
} 

@Benchmark 
public void bigDecimalThaiLocale() { 
    result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
} 

@Benchmark 
public void integerDefaultLocale() { 
    result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
} 

@Benchmark 
public void integerLocaleAlternate() { 
    result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
    other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
} 

@Benchmark 
public void integerThaiLocale() { 
    result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
} 


Before: 
Benchmark Mode Cnt Score Error Units 
MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 

After: 
Benchmark Mode Cnt Score Error Units 
MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

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

Commit messages:
 - Better caching of DecimalFormatSymbols

Changes: https://git.openjdk.java.net/jdk/pull/7703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282625
  Stats: 60 lines in 2 files changed: 27 ins; 27 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From prr at openjdk.java.net  Fri Mar  4 19:10:06 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 4 Mar 2022 19:10:06 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <flAiYSlXjGXC4cguwLIZyH5aNm_n_wHhhiUVZLnQHOw=.55037371-dfc6-481a-965a-703b845542ad@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by prr (Reviewer).

Looks like  there's only one client source code file touched
Most of the client changes are only in jtreg tests - and this is very trivial, so I'm OK with them being included here.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From naoto at openjdk.java.net  Fri Mar  4 19:10:06 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 19:10:06 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>

On Fri, 4 Mar 2022 17:54:20 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Good to see the performance improvement. Since you are adding a new public method, a CSR is needed for this change.

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 194:

> 192:      * Gets the locale used to create this table.
> 193:      *
> 194:      * @return the the locale used to create this table

`table` does not read right here, also `@since 19` is needed.

src/java.base/share/classes/java/util/Formatter.java line 2016:

> 2014:     static DecimalFormatSymbols getDecimalFormatSymbols(Locale locale) {
> 2015:         DecimalFormatSymbols dfs = DFS;
> 2016:         if (dfs != null && dfs.getLocale() == locale) {

`Locale` should be compared using `equals()`.

src/java.base/share/classes/java/util/Formatter.java line 2026:

> 2024:     // Caching zero.
> 2025:     static char getZero(Locale locale) {
> 2026:         return locale == null ? '0' : getDecimalFormatSymbols(locale).getZeroDigit();

While we are at it, it would be beneficial to cache locale-dependent grouping and decimal separators too.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Fri Mar  4 19:22:02 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 4 Mar 2022 19:22:02 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly
In-Reply-To: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
Message-ID: <HHusWvHErS9PkobTJRSQN4S4-huJoWi-wjZwUmpljDQ=.d3942960-7bf4-4ede-9784-f14d09a8dda2@github.com>

On Fri, 4 Mar 2022 18:59:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 194:
> 
>> 192:      * Gets the locale used to create this table.
>> 193:      *
>> 194:      * @return the the locale used to create this table
> 
> `table` does not read right here, also `@since 19` is needed.

Noted.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From rriggs at openjdk.java.net  Fri Mar  4 19:33:06 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 19:33:06 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <w6EtpBynowVBiw_b5nP_UIAIXBanT3tU4iu5g8_e4gM=.24ccf09a-048f-4308-ac77-a8412eb61b71@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From jlaskey at openjdk.java.net  Fri Mar  4 19:38:07 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 4 Mar 2022 19:38:07 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly
In-Reply-To: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
Message-ID: <UJNIgJpCZKQeku_MwKM1MGei3GfzKnIv7o2oMdapcnU=.d3304597-3476-44ae-a1f8-bae411672f67@github.com>

On Fri, 4 Mar 2022 19:00:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> src/java.base/share/classes/java/util/Formatter.java line 2016:
> 
>> 2014:     static DecimalFormatSymbols getDecimalFormatSymbols(Locale locale) {
>> 2015:         DecimalFormatSymbols dfs = DFS;
>> 2016:         if (dfs != null && dfs.getLocale() == locale) {
> 
> `Locale` should be compared using `equals()`.

I know this looks wrong and I debated with myself about it, but 1) Locale equals is complex 2) many Locales are global constants 3) there is a 1-1 correspondence of DecimalFormatSymbols to locale. AFAIK even If two locales describe the same configuration there will be two distinct DecimalFormatSymbols. Is this not the case? I can add a comment to indicate that this is was deliberate decision.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From iris at openjdk.java.net  Fri Mar  4 19:43:03 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 4 Mar 2022 19:43:03 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <MATEadXGlyHBObaz0cYBJT19VmXa5Sk_VcaOKC_AtE8=.c1394e50-8bc7-44ab-bcec-8f3701295187@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice tidy of the code.

Is there anything that can be done to prevent re-introduction of this trivial problem?  Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace?

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From naoto at openjdk.java.net  Fri Mar  4 19:54:04 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 19:54:04 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly
In-Reply-To: <UJNIgJpCZKQeku_MwKM1MGei3GfzKnIv7o2oMdapcnU=.d3304597-3476-44ae-a1f8-bae411672f67@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
 <UJNIgJpCZKQeku_MwKM1MGei3GfzKnIv7o2oMdapcnU=.d3304597-3476-44ae-a1f8-bae411672f67@github.com>
Message-ID: <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com>

On Fri, 4 Mar 2022 19:33:07 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Formatter.java line 2016:
>> 
>>> 2014:     static DecimalFormatSymbols getDecimalFormatSymbols(Locale locale) {
>>> 2015:         DecimalFormatSymbols dfs = DFS;
>>> 2016:         if (dfs != null && dfs.getLocale() == locale) {
>> 
>> `Locale` should be compared using `equals()`.
>
> I know this looks wrong and I debated with myself about it, but 1) Locale equals is complex 2) many Locales are global constants 3) there is a 1-1 correspondence of DecimalFormatSymbols to locale. AFAIK even If two locales describe the same configuration there will be two distinct DecimalFormatSymbols. Is this not the case? I can add a comment to indicate that this is was deliberate decision.

I am afraid people are still using constructors for creating a locale, instead of the factory method that was added later. Since `new Locale("en") == new Locale("en")` returns `false`, I'd still expect `equals()` to compare locales. As to the constants, the number of them is relatively small, IMO.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From wetmore at openjdk.java.net  Fri Mar  4 19:56:03 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Fri, 4 Mar 2022 19:56:03 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <1X39o4ON1uvbSXAp_r66zAmSy6sWZFKaP7-M54vAqX0=.d6abe0d5-9dd2-409b-91df-255d838196cb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

LGTM also.  

Similar suggestion for updating copyrights.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From rriggs at openjdk.java.net  Fri Mar  4 20:04:02 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 20:04:02 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly
In-Reply-To: <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
 <UJNIgJpCZKQeku_MwKM1MGei3GfzKnIv7o2oMdapcnU=.d3304597-3476-44ae-a1f8-bae411672f67@github.com>
 <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com>
Message-ID: <lWGs9BGREiZDWhL-CXtF6PgziyWX5JCn0m_xRJYqv_s=.99262c97-9c86-4b2a-972f-4bffd6829e94@github.com>

On Fri, 4 Mar 2022 19:50:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I know this looks wrong and I debated with myself about it, but 1) Locale equals is complex 2) many Locales are global constants 3) there is a 1-1 correspondence of DecimalFormatSymbols to locale. AFAIK even If two locales describe the same configuration there will be two distinct DecimalFormatSymbols. Is this not the case? I can add a comment to indicate that this is was deliberate decision.
>
> I am afraid people are still using constructors for creating a locale, instead of the factory method that was added later. Since `new Locale("en") == new Locale("en")` returns `false`, I'd still expect `equals()` to compare locales. As to the constants, the number of them is relatively small, IMO.

As a separate/future issue, perhaps the constructors should be deprecated to nudge people to using the static `getInstance` methods.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Fri Mar  4 20:56:47 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 4 Mar 2022 20:56:47 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v2]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <JKvqhEZ5hWJrpZU6WyJa5U1UxjIHhhHlIgodviXV4Lw=.c1ee11bb-cad1-4091-a76e-cb9d9fa9c4a8@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Use Locale equals, add support for decimal/grouping separators and fix comments in DecimalFormatSymbols.getLocale

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/ac2105f3..50944ba0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=00-01

  Stats: 29 lines in 2 files changed: 14 ins; 9 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Fri Mar  4 21:17:50 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 4 Mar 2022 21:17:50 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Too many 'the'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/50944ba0..9ac0c283

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From rriggs at openjdk.java.net  Fri Mar  4 21:26:00 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 21:26:00 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <lWGs9BGREiZDWhL-CXtF6PgziyWX5JCn0m_xRJYqv_s=.99262c97-9c86-4b2a-972f-4bffd6829e94@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
 <UJNIgJpCZKQeku_MwKM1MGei3GfzKnIv7o2oMdapcnU=.d3304597-3476-44ae-a1f8-bae411672f67@github.com>
 <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com>
 <lWGs9BGREiZDWhL-CXtF6PgziyWX5JCn0m_xRJYqv_s=.99262c97-9c86-4b2a-972f-4bffd6829e94@github.com>
Message-ID: <EzDQNDItptCDLIJCTCL_YYTDk6iKo4S6VvyBEVv_1ds=.5f947887-05f6-4e4c-bfbd-a117290d0207@github.com>

On Fri, 4 Mar 2022 20:00:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I am afraid people are still using constructors for creating a locale, instead of the factory method that was added later. Since `new Locale("en") == new Locale("en")` returns `false`, I'd still expect `equals()` to compare locales. As to the constants, the number of them is relatively small, IMO.
>
> As a separate/future issue, perhaps the constructors should be deprecated to nudge people to using the static `getInstance` methods.

Would it be just as effective and improve performance more broadly to cache in DecimalFormatSymbols.getInstance()?

Declarations should be private unless there is a package need.
In this case, the only access to should be via the method.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From rriggs at openjdk.java.net  Fri Mar  4 21:26:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 21:26:01 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
Message-ID: <OcDP2bHFy7srlLNqyTVEWhMjqPTVIspS0Xker5H5NXk=.f5af6df6-327e-4331-8abd-dd47431b15b5@github.com>

On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Too many 'the'

src/java.base/share/classes/java/util/Formatter.java line 2025:

> 2023: 
> 2024:     // Caching zero.
> 2025:     static char getZero(Locale locale) {

Perhaps should be private.
The comment says caching zero, but its really the DecimalFormatSymbols that are cached.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From joehw at openjdk.java.net  Fri Mar  4 21:30:01 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 4 Mar 2022 21:30:01 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v2]
In-Reply-To: <fvSGh0a86O7VEKQn4YA3uro576viuy5nmOXlVExQViM=.510416dc-33fa-4b4b-9a5a-35a08e261d07@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <fvSGh0a86O7VEKQn4YA3uro576viuy5nmOXlVExQViM=.510416dc-33fa-4b4b-9a5a-35a08e261d07@github.com>
Message-ID: <I6bRpqdNNTkbXK5xc_mSmf75A5ZyZ05eRSt37mkBgvA=.e0251de6-90ec-46bc-bcf5-826f21f118b3@github.com>

On Fri, 4 Mar 2022 05:02:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year fix

Is the public API change, adding the isIsoLike() method, necessary? It seems to me we already have the isSupported method? for that purpose and plus isSupportedBy? from the IsoFields. Would making sure the IsoFields are supported at the implementation level be sufficient?

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From darcy at openjdk.java.net  Fri Mar  4 21:33:07 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 21:33:07 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <Fk4CQf_wtrFu81GCs38UEX3qnk9nz3DUkP7EZT37icU=.78ef4ece-fe43-4b9a-b4c4-393e7bf741cb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From naoto at openjdk.java.net  Fri Mar  4 21:35:14 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 21:35:14 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
Message-ID: <h0cSsB0hKHN690ro43Mc0N3pBwPNF1yKVAMagAwT_9o=.ed86969b-29e3-46e9-8cf4-fa146ccb5aa1@github.com>

On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Too many 'the'

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192:

> 190: 
> 191:     /**
> 192:      * Gets the locale used to create this instance.

Nit: Since `@return` has the same description, `{@return ...}` can be used here.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From rriggs at openjdk.java.net  Fri Mar  4 21:42:05 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Mar 2022 21:42:05 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v2]
In-Reply-To: <fvSGh0a86O7VEKQn4YA3uro576viuy5nmOXlVExQViM=.510416dc-33fa-4b4b-9a5a-35a08e261d07@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <fvSGh0a86O7VEKQn4YA3uro576viuy5nmOXlVExQViM=.510416dc-33fa-4b4b-9a5a-35a08e261d07@github.com>
Message-ID: <sgrsp9lZZpUT4YBGbTjMw-FPez4USAGzuKgQ0_Raurk=.0b652e17-028f-4e64-b6ec-f1ef7b55c354@github.com>

On Fri, 4 Mar 2022 05:02:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year fix

src/java.base/share/classes/java/time/chrono/Chronology.java line 792:

> 790:      * @since 19
> 791:      */
> 792:     default boolean isIsoLike() {

Maybe a bit late for a name change...

How about the method name being:  `supportsIsoFields()`.

IsoLike seem pretty wishy washy.

src/java.base/share/classes/java/time/chrono/IsoChronology.java line 682:

> 680:     //-----------------------------------------------------------------------
> 681:     /**
> 682:      * {@inheritDoc}

I would rather see the statement indicating that ISOChronology returns true; not a generic sentence.
(For each of the Chronologies).

"IsoChronology supports ISO based fields, such as DAY_OF_QUARTER and QUARTER_OF_YEAR."

src/java.base/share/classes/java/time/temporal/IsoFields.java line 599:

> 597:         private static void ensureIsoLike(TemporalAccessor temporal) {
> 598:             if (!isIsoLike(temporal)) {
> 599:                 throw new DateTimeException("Resolve requires ISO-like Chronology");

Would the exception be easier to debug with if it mentioned the chronology that is not ISO-like?

test/jdk/java/time/test/java/time/temporal/TestIsoWeekFields.java line 132:

> 130:     public void test_Unit_isSupportedBy_ISO() {
> 131:         assertEquals(IsoFields.WEEK_BASED_YEARS.isSupportedBy(LocalDate.now()),true);
> 132:         assertEquals(IsoFields.WEEK_BASED_YEARS.isSupportedBy(ThaiBuddhistDate.now()),true);

Typically, comma (",") is followed by space.

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From naoto at openjdk.java.net  Fri Mar  4 21:54:04 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 21:54:04 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v2]
In-Reply-To: <fvSGh0a86O7VEKQn4YA3uro576viuy5nmOXlVExQViM=.510416dc-33fa-4b4b-9a5a-35a08e261d07@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <fvSGh0a86O7VEKQn4YA3uro576viuy5nmOXlVExQViM=.510416dc-33fa-4b4b-9a5a-35a08e261d07@github.com>
Message-ID: <W3gX28Uxq8gULqQRsuwlIsihel2QfV2Hfk3XiNk28qw=.f8cd93cd-5980-447f-a773-dd2c10b5ca75@github.com>

On Fri, 4 Mar 2022 05:02:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year fix

>

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From naoto at openjdk.java.net  Fri Mar  4 21:57:56 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 21:57:56 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v2]
In-Reply-To: <I6bRpqdNNTkbXK5xc_mSmf75A5ZyZ05eRSt37mkBgvA=.e0251de6-90ec-46bc-bcf5-826f21f118b3@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <fvSGh0a86O7VEKQn4YA3uro576viuy5nmOXlVExQViM=.510416dc-33fa-4b4b-9a5a-35a08e261d07@github.com>
 <I6bRpqdNNTkbXK5xc_mSmf75A5ZyZ05eRSt37mkBgvA=.e0251de6-90ec-46bc-bcf5-826f21f118b3@github.com>
Message-ID: <IJUmGBFg2UD_uPWzuVJs3IVqoJyTtpDtQOzz4iaN_5I=.c99a697a-b9b0-4c42-be4a-4284e1dd98b7@github.com>

On Fri, 4 Mar 2022 21:26:57 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Is the public API change, adding the isIsoLike() method, necessary?

Yes, I believe so. Without a means to tell whether the `TemporalAccessor`, such as `LocalDate`, supports `IsoFields`, `IsoFields` would have to hard-code which temporal accessor is supporting `IsoFields` fields.

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From naoto at openjdk.java.net  Fri Mar  4 23:05:56 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 4 Mar 2022 23:05:56 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v3]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <kysKi5XVOk8Y5FlVJqYzr8rWQ2UMRcMPROof7-4OCKA=.c0fa933c-b1de-4aee-a075-f40d893fdf87@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

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

  Addresses review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/12c6212a..e0b329d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=01-02

  Stats: 52 lines in 10 files changed: 11 ins; 0 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From dholmes at openjdk.java.net  Sat Mar  5 05:52:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 5 Mar 2022 05:52:04 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <2NJw-71OOOvNs9519H__uYdXQnJm23L-Ez4jKoAuKrk=.c277d644-fd63-442e-99a1-6d3d66cb3405@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

I eyeballed the diff file and all seems okay.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7268

From jwaters at openjdk.java.net  Sat Mar  5 06:52:13 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Sat, 5 Mar 2022 06:52:13 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

Nice, good work matteo

Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From duke at openjdk.java.net  Sat Mar  5 07:22:03 2022
From: duke at openjdk.java.net (Jan =?UTF-8?B?U2NobMO2w59pbg==?=)
Date: Sat, 5 Mar 2022 07:22:03 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <apFWxhCWJTH2dzbDsF-uJEef-Y6uhfH0gNI48VGHYwU=.8dfe6837-793d-466f-bb16-9f7fd53798d8@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

This PR changes a comment in javax/swing/RepaintManager.java. This commented out code should be removed altogether in another PR? Because its an System.out.println and because its commented out code.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From jpai at openjdk.java.net  Sat Mar  5 14:23:59 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 5 Mar 2022 14:23:59 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
Message-ID: <UbollPNIZjOE2see_EuFSH-RTV016Ot93S-l88n8g0Y=.f9293a8a-d641-4cfc-93af-74f6e74fc2c0@github.com>

On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Too many 'the'

src/java.base/share/classes/java/util/Formatter.java line 2012:

> 2010: public final class Formatter implements Closeable, Flushable {
> 2011:     // Caching DecimalFormatSymbols
> 2012:     static DecimalFormatSymbols DFS = null;

Hello Jim,
The javadoc of `Formatter` states:

>
> Formatters are not necessarily safe for multithreaded access.  Thread safety is optional and is the responsibility of users of methods in this class.
>

So I would think that user applications would typically be synchronizing on the instance of a `Formatter` for any multi-threaded use of a formatter instance.

If I'm reading this changed code correctly, it's now possible that 2 separate instances of a `Formatter` being concurrently accessed (i.e. in different threads) will now try and update/use this cached class level `static` state `DFS`. That would thus require some kind of thread safety semantics to be implemented for this new `getDecimalFormatSymbols(Locale)` method, isn't it?

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jpai at openjdk.java.net  Sun Mar  6 15:04:06 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 6 Mar 2022 15:04:06 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <UbollPNIZjOE2see_EuFSH-RTV016Ot93S-l88n8g0Y=.f9293a8a-d641-4cfc-93af-74f6e74fc2c0@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
 <UbollPNIZjOE2see_EuFSH-RTV016Ot93S-l88n8g0Y=.f9293a8a-d641-4cfc-93af-74f6e74fc2c0@github.com>
Message-ID: <kB_0TI18F8WIfPuqnKk_DwEmD1tB5EkVOLiRvVkvVNs=.33793ca3-cab1-4752-ac9a-23c1c42fbabd@github.com>

On Sat, 5 Mar 2022 14:20:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> will now try and update/use this cached class level static state DFS. That would thus require some kind of thread safety semantics to be implemented for this new getDecimalFormatSymbols(Locale) method, isn't it?

A bit more closer look at the code and it appears to me that the use of :

DecimalFormatSymbols dfs = DFS;

and then working off that local variable prevents any kind of race issues that might be caused due to multi-thread access. Of course it still means that multiple threads might still go ahead and do a:

dfs = DecimalFormatSymbols.getInstance(locale);

on first access (when `DFS` is null) but that in itself should be harmless.

If this is intentional (which I suspect it is), should some comment be added in this method explaining this multi-thread access detail?

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From scolebourne at openjdk.java.net  Sun Mar  6 17:20:03 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Sun, 6 Mar 2022 17:20:03 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v3]
In-Reply-To: <kysKi5XVOk8Y5FlVJqYzr8rWQ2UMRcMPROof7-4OCKA=.c0fa933c-b1de-4aee-a075-f40d893fdf87@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <kysKi5XVOk8Y5FlVJqYzr8rWQ2UMRcMPROof7-4OCKA=.c0fa933c-b1de-4aee-a075-f40d893fdf87@github.com>
Message-ID: <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com>

On Fri, 4 Mar 2022 23:05:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses review comments

src/java.base/share/classes/java/time/chrono/Chronology.java line 794:

> 792:      * @since 19
> 793:      */
> 794:     default boolean supportsIsoFields() {

I'm not a fan of this name, as it is inconsistent with the rest of JSR310 API, which uses an `is` prefix for booleans. I suggested `isIsoLike` because the key question is whether the chronology is "like" ISO. I would also be OK with `isBasedOnIso`, `isDerivedFromIso`, `isIsoBased` or something similar. Another risk here is limiting the method to refer only to `IsoFields`. While that is the use case here, it isn't the case that the only fields that might be affected are in `IsoFields`. Third parties may have  their own fields that are suitable for use with an ISO-like chronology.

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From naoto at openjdk.java.net  Mon Mar  7 00:37:07 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 7 Mar 2022 00:37:07 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <kB_0TI18F8WIfPuqnKk_DwEmD1tB5EkVOLiRvVkvVNs=.33793ca3-cab1-4752-ac9a-23c1c42fbabd@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
 <UbollPNIZjOE2see_EuFSH-RTV016Ot93S-l88n8g0Y=.f9293a8a-d641-4cfc-93af-74f6e74fc2c0@github.com>
 <kB_0TI18F8WIfPuqnKk_DwEmD1tB5EkVOLiRvVkvVNs=.33793ca3-cab1-4752-ac9a-23c1c42fbabd@github.com>
Message-ID: <9g47OUC6AaV2e1baWOmanc9ISVbA5hZKq2IdjYWw36s=.3d31f016-047e-4f60-a5e0-0113783bda43@github.com>

On Sun, 6 Mar 2022 15:00:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Formatter.java line 2012:
>> 
>>> 2010: public final class Formatter implements Closeable, Flushable {
>>> 2011:     // Caching DecimalFormatSymbols
>>> 2012:     static DecimalFormatSymbols DFS = null;
>> 
>> Hello Jim,
>> The javadoc of `Formatter` states:
>> 
>>>
>>> Formatters are not necessarily safe for multithreaded access.  Thread safety is optional and is the responsibility of users of methods in this class.
>>>
>> 
>> So I would think that user applications would typically be synchronizing on the instance of a `Formatter` for any multi-threaded use of a formatter instance.
>> 
>> If I'm reading this changed code correctly, even if user applications have properly synchronized on a `Formatter` instance, it's now possible that 2 separate instances of a `Formatter` being concurrently accessed (i.e. in different threads) will now try and update/use this cached class level `static` state `DFS`. That would thus require some kind of thread safety semantics to be implemented for this new `getDecimalFormatSymbols(Locale)` method, isn't it?
>
>> will now try and update/use this cached class level static state DFS. That would thus require some kind of thread safety semantics to be implemented for this new getDecimalFormatSymbols(Locale) method, isn't it?
> 
> A bit more closer look at the code and it appears to me that the use of :
> 
> DecimalFormatSymbols dfs = DFS;
> 
> and then working off that local variable prevents any kind of race issues that might be caused due to multi-thread access. Of course it still means that multiple threads might still go ahead and do a:
> 
> dfs = DecimalFormatSymbols.getInstance(locale);
> 
> on first access (when `DFS` is null) but that in itself should be harmless.
> 
> If this is intentional (which I suspect it is), should some comment be added in this method explaining this multi-thread access detail?

Initially, I thought of the same thing (not the `Formatter` but `DecimalFormatSymbols` itself, as it is also not thread safe), but I concluded it was OK, as there is no mutation going on. I agree with Jaikiran that some comments might help here.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From naoto at openjdk.java.net  Mon Mar  7 01:31:06 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 7 Mar 2022 01:31:06 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v3]
In-Reply-To: <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <kysKi5XVOk8Y5FlVJqYzr8rWQ2UMRcMPROof7-4OCKA=.c0fa933c-b1de-4aee-a075-f40d893fdf87@github.com>
 <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com>
Message-ID: <aHbUIBPMoOkuXP9OARaXl5UFFaivdP78b-4bMGQYrQE=.ab52e2ec-8635-46c4-bf02-2a3ac932f6a8@github.com>

On Sun, 6 Mar 2022 17:12:31 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addresses review comments
>
> src/java.base/share/classes/java/time/chrono/Chronology.java line 794:
> 
>> 792:      * @since 19
>> 793:      */
>> 794:     default boolean supportsIsoFields() {
> 
> I'm not a fan of this name, as it is inconsistent with the rest of JSR310 API, which uses an `is` prefix for booleans. I suggested `isIsoLike` because the key question is whether the chronology is "like" ISO. I would also be OK with `isBasedOnIso`, `isDerivedFromIso`, `isIsoBased` or something similar. Another risk here is limiting the method to refer only to `IsoFields`. While that is the use case here, it isn't the case that the only fields that might be affected are in `IsoFields`. Third parties may have  their own fields that are suitable for use with an ISO-like chronology.

OK, I propose `isIsoBased()` for the name, which I initially thought of. If there is no objection, I will modify the spec/impl.

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From rriggs at openjdk.java.net  Mon Mar  7 03:04:05 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 7 Mar 2022 03:04:05 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v3]
In-Reply-To: <aHbUIBPMoOkuXP9OARaXl5UFFaivdP78b-4bMGQYrQE=.ab52e2ec-8635-46c4-bf02-2a3ac932f6a8@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <kysKi5XVOk8Y5FlVJqYzr8rWQ2UMRcMPROof7-4OCKA=.c0fa933c-b1de-4aee-a075-f40d893fdf87@github.com>
 <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com>
 <aHbUIBPMoOkuXP9OARaXl5UFFaivdP78b-4bMGQYrQE=.ab52e2ec-8635-46c4-bf02-2a3ac932f6a8@github.com>
Message-ID: <ICazkUAoMBu6XvJt7A6AU_O-jHO4O1YF_pcw9UwoSy0=.38ef179c-5cb0-4aac-864b-798f27f9187c@github.com>

On Mon, 7 Mar 2022 01:27:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/chrono/Chronology.java line 794:
>> 
>>> 792:      * @since 19
>>> 793:      */
>>> 794:     default boolean supportsIsoFields() {
>> 
>> I'm not a fan of this name, as it is inconsistent with the rest of JSR310 API, which uses an `is` prefix for booleans. I suggested `isIsoLike` because the key question is whether the chronology is "like" ISO. I would also be OK with `isBasedOnIso`, `isDerivedFromIso`, `isIsoBased` or something similar. Another risk here is limiting the method to refer only to `IsoFields`. While that is the use case here, it isn't the case that the only fields that might be affected are in `IsoFields`. Third parties may have  their own fields that are suitable for use with an ISO-like chronology.
>
> OK, I propose `isIsoBased()` for the name, which I initially thought of. If there is no objection, I will modify the spec/impl.

Is `IsoBased` is fine with me.  "isISOLike" is too vague.

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From scolebourne at openjdk.java.net  Mon Mar  7 08:27:59 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 7 Mar 2022 08:27:59 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
Message-ID: <OqhMYfxCrTXWIPZ6Pu4T8JnDoO-EzoufT1H0rBwEC3w=.99fa3fa9-2229-433c-8c7b-8abb614206b8@github.com>

On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Too many 'the'

Just to note that there is also some caching in `DecimalStyle`. It might be possible to reuse `DecimalStyle` here (if it was extended to support grouping separators).

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Mon Mar  7 13:08:08 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 13:08:08 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <EzDQNDItptCDLIJCTCL_YYTDk6iKo4S6VvyBEVv_1ds=.5f947887-05f6-4e4c-bfbd-a117290d0207@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
 <UJNIgJpCZKQeku_MwKM1MGei3GfzKnIv7o2oMdapcnU=.d3304597-3476-44ae-a1f8-bae411672f67@github.com>
 <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com>
 <lWGs9BGREiZDWhL-CXtF6PgziyWX5JCn0m_xRJYqv_s=.99262c97-9c86-4b2a-972f-4bffd6829e94@github.com>
 <EzDQNDItptCDLIJCTCL_YYTDk6iKo4S6VvyBEVv_1ds=.5f947887-05f6-4e4c-bfbd-a117290d0207@github.com>
Message-ID: <fjEWUbyK6N19Mjn11Fgab1UFraqSixyWZ2duzQoc9wI=.6dc7e81c-67f9-4e9c-8ea7-db23538b6fe6@github.com>

On Fri, 4 Mar 2022 21:14:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> As a separate/future issue, perhaps the constructors should be deprecated to nudge people to using the static `getInstance` methods.
>
> Would it be just as effective and improve performance more broadly to cache in DecimalFormatSymbols.getInstance()?
> 
> Declarations should be private unless there is a package need.
> In this case, the only access to should be via the method.

Will investigate

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Mon Mar  7 13:08:10 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 13:08:10 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
Message-ID: <pmIDO7pL_YCiWNFPdancGZAkKUPulhXS52fni8o8nwM=.9d4d6f20-bedd-4c5b-bcbb-cfb0c75e08c3@github.com>

On Fri, 4 Mar 2022 19:02:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Too many 'the'
>
> src/java.base/share/classes/java/util/Formatter.java line 2026:
> 
>> 2024:     // Caching zero.
>> 2025:     static char getZero(Locale locale) {
>> 2026:         return locale == null ? '0' : getDecimalFormatSymbols(locale).getZeroDigit();
> 
> While we are at it, it would be beneficial to cache locale-dependent grouping and decimal separators too.

Noted

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Mon Mar  7 13:20:08 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 13:20:08 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <OqhMYfxCrTXWIPZ6Pu4T8JnDoO-EzoufT1H0rBwEC3w=.99fa3fa9-2229-433c-8c7b-8abb614206b8@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
 <OqhMYfxCrTXWIPZ6Pu4T8JnDoO-EzoufT1H0rBwEC3w=.99fa3fa9-2229-433c-8c7b-8abb614206b8@github.com>
Message-ID: <DmWCjSYTSxP73n7RfW263owrepfrzxvKWXR9NZqMwJY=.45320c5f-7038-4d1d-8824-f6e88d8702b7@github.com>

On Mon, 7 Mar 2022 08:25:19 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Too many 'the'
>
> Just to note that there is also some caching in `DecimalStyle`. It might be possible to reuse `DecimalStyle` here (if it was extended to support grouping separators).

@jodastephen True that. It would also be nice if `DecimalFormatSymbols` also contained grouping size. Will investigate but will use a separate PR for the fallout.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Mon Mar  7 13:20:09 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 13:20:09 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <9g47OUC6AaV2e1baWOmanc9ISVbA5hZKq2IdjYWw36s=.3d31f016-047e-4f60-a5e0-0113783bda43@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
 <UbollPNIZjOE2see_EuFSH-RTV016Ot93S-l88n8g0Y=.f9293a8a-d641-4cfc-93af-74f6e74fc2c0@github.com>
 <kB_0TI18F8WIfPuqnKk_DwEmD1tB5EkVOLiRvVkvVNs=.33793ca3-cab1-4752-ac9a-23c1c42fbabd@github.com>
 <9g47OUC6AaV2e1baWOmanc9ISVbA5hZKq2IdjYWw36s=.3d31f016-047e-4f60-a5e0-0113783bda43@github.com>
Message-ID: <4LdL1Bc2Gt0OAiNRMgCO0hcdgJyLvnPF44cQ3TazojU=.ae0e8d65-6b45-4a14-b7b0-7094658c7a51@github.com>

On Mon, 7 Mar 2022 00:33:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> will now try and update/use this cached class level static state DFS. That would thus require some kind of thread safety semantics to be implemented for this new getDecimalFormatSymbols(Locale) method, isn't it?
>> 
>> A bit more closer look at the code and it appears to me that the use of :
>> 
>> DecimalFormatSymbols dfs = DFS;
>> 
>> and then working off that local variable prevents any kind of race issues that might be caused due to multi-thread access. Of course it still means that multiple threads might still go ahead and do a:
>> 
>> dfs = DecimalFormatSymbols.getInstance(locale);
>> 
>> on first access (when `DFS` is null) but that in itself should be harmless.
>> 
>> If this is intentional (which I suspect it is), should some comment be added in this method explaining this multi-thread access detail?
>
> Initially, I thought of the same thing (not the `Formatter` but `DecimalFormatSymbols` itself, as it is also not thread safe), but I concluded it was OK, as there is no mutation going on. I agree with Jaikiran that some comments might help here.

Noted

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Mon Mar  7 13:20:10 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 13:20:10 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <OcDP2bHFy7srlLNqyTVEWhMjqPTVIspS0Xker5H5NXk=.f5af6df6-327e-4331-8abd-dd47431b15b5@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <tkhUAxexIgWs6Cy327PnoPjLEfjuFad1aAKQ2b1dUek=.a35c3bbd-e3b6-4f2f-94b5-ed05e36505c2@github.com>
 <OcDP2bHFy7srlLNqyTVEWhMjqPTVIspS0Xker5H5NXk=.f5af6df6-327e-4331-8abd-dd47431b15b5@github.com>
Message-ID: <YuNLgPpMTJ9Igscemp97rJUh7I6NLplN17UTrFaU5aY=.d80115df-1a0c-48c4-85ff-452966232f2b@github.com>

On Fri, 4 Mar 2022 20:04:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Too many 'the'
>
> src/java.base/share/classes/java/util/Formatter.java line 2025:
> 
>> 2023: 
>> 2024:     // Caching zero.
>> 2025:     static char getZero(Locale locale) {
> 
> Perhaps should be private.
> The comment says caching zero, but its really the DecimalFormatSymbols that are cached.

Noted.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From erikj at openjdk.java.net  Mon Mar  7 13:44:05 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 7 Mar 2022 13:44:05 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
Message-ID: <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>

On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?

They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From jlaskey at openjdk.java.net  Mon Mar  7 14:27:07 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 14:27:07 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v3]
In-Reply-To: <fjEWUbyK6N19Mjn11Fgab1UFraqSixyWZ2duzQoc9wI=.6dc7e81c-67f9-4e9c-8ea7-db23538b6fe6@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com>
 <UJNIgJpCZKQeku_MwKM1MGei3GfzKnIv7o2oMdapcnU=.d3304597-3476-44ae-a1f8-bae411672f67@github.com>
 <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com>
 <lWGs9BGREiZDWhL-CXtF6PgziyWX5JCn0m_xRJYqv_s=.99262c97-9c86-4b2a-972f-4bffd6829e94@github.com>
 <EzDQNDItptCDLIJCTCL_YYTDk6iKo4S6VvyBEVv_1ds=.5f947887-05f6-4e4c-bfbd-a117290d0207@github.com>
 <fjEWUbyK6N19Mjn11Fgab1UFraqSixyWZ2duzQoc9wI=.6dc7e81c-67f9-4e9c-8ea7-db23538b6fe6@github.com>
Message-ID: <UMHjIBRlXEdG6RwvNNbeKfgeftZHS7oy7e_BMR37oXg=.4b620bec-16b8-41cd-ac1e-8b3b6dde49b8@github.com>

On Mon, 7 Mar 2022 13:05:09 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Would it be just as effective and improve performance more broadly to cache in DecimalFormatSymbols.getInstance()?
>> 
>> Declarations should be private unless there is a package need.
>> In this case, the only access to should be via the method.
>
> Will investigate

Performance is on par when cached in DecimalFormatSymbols. Will switch to that direction.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Mon Mar  7 14:45:44 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 14:45:44 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v4]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <NJfjFFJQdzoiICPG6Cbs_735VdbdcLEHzARNrzFYRmI=.b51ef016-4bfd-42d5-b972-09d9a052cf40@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation.
 - Edits from PR comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/9ac0c283..fcbf66a2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=02-03

  Stats: 36 lines in 2 files changed: 17 ins; 9 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Mon Mar  7 14:52:16 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 14:52:16 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v5]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <GbzR6aIFA-Y-5WRlWY4o2b025RwOHbsSVGek_U72RNk=.3d58c5d1-536d-4a34-8d41-b0f46d141ac7@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Drop DecimalFormatSymbols.getLocale change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/fcbf66a2..b93cdb03

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=03-04

  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From jwaters at openjdk.java.net  Mon Mar  7 16:24:00 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Mon, 7 Mar 2022 16:24:00 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <BYP-9VZJoznj9GWtwXRA99BqEtITgNUVrbDggKRdads=.8664f68e-92af-4dad-99c3-a7b0bb0e1e68@github.com>
 <Axd1QHFh-k8zh76bMceeni5kEH2N5sU7O5JxGIt6bN8=.2186d5f3-deec-4540-8db4-b8548fe6286b@github.com>
Message-ID: <WUgibFurfKq3h0sqZ2YDVuSbxl-gxhmgJPnoUPWpeX4=.7af5c5e5-a326-4708-9eb9-d64f41c9af7c@github.com>

On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change?
> 
> They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you.

Alright, I can't change the title of the PR, I guess it'll be easier for me to change the issue instead

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From lancea at openjdk.java.net  Mon Mar  7 16:43:08 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 7 Mar 2022 16:43:08 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

What problem are you having editing the PR header?   You should be able to do so as the author of the PR

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From kcr at openjdk.java.net  Mon Mar  7 16:52:07 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:52:07 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
Message-ID: <OlXgsLnUYvaXKuqKPGlg36JcuDUmXp8jC-8P6Y2o35k=.e68e429a-72b7-4828-9ea6-2be0165d2cdf@github.com>

On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> What problem are you having editing the PR header? You should be able to do so as the author of the PR

Exactly. You should see an "Edit" button near the right edge of the PR title. See the attached image:

![PR-title](https://user-images.githubusercontent.com/34689748/157079404-eadbe8be-ae94-41e0-b17b-0d1a8026b9da.png)

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From kcr at openjdk.java.net  Mon Mar  7 16:56:06 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 16:56:06 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <ya35_llZyJFaqTkVaOv3ybkki4iCaQUTO_PPCw8XaPg=.eb0e2be9-5ed0-4be8-8a14-47f573b6dbfb@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

But as the JBS title and PR title now match, this is a moot point.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From joehw at openjdk.java.net  Mon Mar  7 17:08:06 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 7 Mar 2022 17:08:06 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v3]
In-Reply-To: <ICazkUAoMBu6XvJt7A6AU_O-jHO4O1YF_pcw9UwoSy0=.38ef179c-5cb0-4aac-864b-798f27f9187c@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <kysKi5XVOk8Y5FlVJqYzr8rWQ2UMRcMPROof7-4OCKA=.c0fa933c-b1de-4aee-a075-f40d893fdf87@github.com>
 <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com>
 <aHbUIBPMoOkuXP9OARaXl5UFFaivdP78b-4bMGQYrQE=.ab52e2ec-8635-46c4-bf02-2a3ac932f6a8@github.com>
 <ICazkUAoMBu6XvJt7A6AU_O-jHO4O1YF_pcw9UwoSy0=.38ef179c-5cb0-4aac-864b-798f27f9187c@github.com>
Message-ID: <ExI5Ey6bC5qLtrlvkPDH3x_pkQ85xizOYWsxv8Ah7Ks=.88fda794-a7b9-4e6f-b7c6-fc180b488746@github.com>

On Mon, 7 Mar 2022 03:00:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> OK, I propose `isIsoBased()` for the name, which I initially thought of. If there is no objection, I will modify the spec/impl.
>
> Is `IsoBased` is fine with me.  "isISOLike" is too vague.

That matches the javadoc as well, that it "supports ISO based fields".

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From kcr at openjdk.java.net  Mon Mar  7 17:18:03 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
 <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>
Message-ID: <gU_j20iocr_5kNAxvBLGmM3fgGRXQdnmguOWyMdIe4E=.d980a805-e168-4a7d-b9d9-a1a09df4b870@github.com>

On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.

Ah, that explains it then.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From ihse at openjdk.java.net  Mon Mar  7 17:18:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Mar 2022 17:18:03 GMT
Subject: <i18n dev> RFR: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
 <zxiwRPwKqEwnlqN--6XI21FbNtZZYGK0dPBrN7WX4TE=.b2afb493-54b3-4946-b461-69b467a993b7@github.com>
Message-ID: <dBlj9TBpXi1bkSF7MrLzM2Sr_v5Hr4UUzLBYf3J63FY=.e99bba44-af79-4c57-b448-5e5a38633760@github.com>

On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi
>> 
>> I have reviewed the code for removing double semicolons at the end of lines
>> 
>> all the best
>> matteo
>
> What problem are you having editing the PR header?   You should be able to do so as the author of the PR

@LanceAndersen @kevinrushforth TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue.

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From jlaskey at openjdk.java.net  Mon Mar  7 17:09:37 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 17:09:37 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v6]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <sxgXIbN2HShOSiuT5Da6QGaM8h5NlQqobad081pFZg4=.80c70a2c-c2bc-47d7-a678-5149ec588eb6@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Correct caching test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/b93cdb03..bf797539

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From naoto at openjdk.java.net  Mon Mar  7 18:20:43 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 7 Mar 2022 18:20:43 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v4]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <xU_V8M12iPdF1pfq8otYMUBsFo4AImj1lzlBeq5UzGk=.61281911-a2cc-422f-b0e3-bacdcdcf4ef9@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

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

 - Renamed the new method
 - Merge branch 'master' into JDK-8279185
 - Addresses review comments
 - copyright year fix
 - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/e0b329d7..530ed40e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=02-03

  Stats: 12800 lines in 349 files changed: 8488 ins; 2645 del; 1667 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From naoto at openjdk.java.net  Mon Mar  7 18:26:09 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 7 Mar 2022 18:26:09 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v3]
In-Reply-To: <ExI5Ey6bC5qLtrlvkPDH3x_pkQ85xizOYWsxv8Ah7Ks=.88fda794-a7b9-4e6f-b7c6-fc180b488746@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <kysKi5XVOk8Y5FlVJqYzr8rWQ2UMRcMPROof7-4OCKA=.c0fa933c-b1de-4aee-a075-f40d893fdf87@github.com>
 <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com>
 <aHbUIBPMoOkuXP9OARaXl5UFFaivdP78b-4bMGQYrQE=.ab52e2ec-8635-46c4-bf02-2a3ac932f6a8@github.com>
 <ICazkUAoMBu6XvJt7A6AU_O-jHO4O1YF_pcw9UwoSy0=.38ef179c-5cb0-4aac-864b-798f27f9187c@github.com>
 <ExI5Ey6bC5qLtrlvkPDH3x_pkQ85xizOYWsxv8Ah7Ks=.88fda794-a7b9-4e6f-b7c6-fc180b488746@github.com>
Message-ID: <8ibI3t0cbrKyoDcNX0XPkIXKecA12_eHCQvHH6LU4KM=.83ec1895-35c4-49c4-927b-71c3ceca2fca@github.com>

On Mon, 7 Mar 2022 17:04:25 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Is `IsoBased` is fine with me.  "isISOLike" is too vague.
>
> That matches the javadoc as well, that it "supports ISO based fields".

Renamed the new method to `isIsoBased()`. Modified the CSR accordingly.

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From joehw at openjdk.java.net  Mon Mar  7 18:34:05 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 7 Mar 2022 18:34:05 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v4]
In-Reply-To: <xU_V8M12iPdF1pfq8otYMUBsFo4AImj1lzlBeq5UzGk=.61281911-a2cc-422f-b0e3-bacdcdcf4ef9@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <xU_V8M12iPdF1pfq8otYMUBsFo4AImj1lzlBeq5UzGk=.61281911-a2cc-422f-b0e3-bacdcdcf4ef9@github.com>
Message-ID: <7sYLKTu76eFlmU46Pp6qmZENqYF1yUqvdgAsnVsrIQw=.9b5b2f51-ee65-4ec1-b515-e5d01ae1fca4@github.com>

On Mon, 7 Mar 2022 18:20:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> 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 five additional commits since the last revision:
> 
>  - Renamed the new method
>  - Merge branch 'master' into JDK-8279185
>  - Addresses review comments
>  - copyright year fix
>  - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

src/java.base/share/classes/java/time/chrono/IsoChronology.java line 689:

> 687:      */
> 688:     @Override
> 689:     public boolean isIsoBased() {

Is this meant to be 'default'?  The CSR indicated adding default methods.

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From naoto at openjdk.java.net  Mon Mar  7 18:50:07 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 7 Mar 2022 18:50:07 GMT
Subject: <i18n dev> RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v4]
In-Reply-To: <7sYLKTu76eFlmU46Pp6qmZENqYF1yUqvdgAsnVsrIQw=.9b5b2f51-ee65-4ec1-b515-e5d01ae1fca4@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <xU_V8M12iPdF1pfq8otYMUBsFo4AImj1lzlBeq5UzGk=.61281911-a2cc-422f-b0e3-bacdcdcf4ef9@github.com>
 <7sYLKTu76eFlmU46Pp6qmZENqYF1yUqvdgAsnVsrIQw=.9b5b2f51-ee65-4ec1-b515-e5d01ae1fca4@github.com>
Message-ID: <ucKaEUGnoyUsBcAcaFACas08nOBCiORubc440zNEmsQ=.786716c6-8173-4b91-9218-c518c4b6870e@github.com>

On Mon, 7 Mar 2022 18:30:28 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Renamed the new method
>>  - Merge branch 'master' into JDK-8279185
>>  - Addresses review comments
>>  - copyright year fix
>>  - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate
>
> src/java.base/share/classes/java/time/chrono/IsoChronology.java line 689:
> 
>> 687:      */
>> 688:     @Override
>> 689:     public boolean isIsoBased() {
> 
> Is this meant to be 'default'?  The CSR indicated adding default methods.

The `default` method has been added to `java.time.chrono.Chronology` interface. This is its overridden method implemented in `IsoChronology` concrete class.

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

PR: https://git.openjdk.java.net/jdk/pull/7683

From jlaskey at openjdk.java.net  Mon Mar  7 20:36:38 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 20:36:38 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v6]
In-Reply-To: <sxgXIbN2HShOSiuT5Da6QGaM8h5NlQqobad081pFZg4=.80c70a2c-c2bc-47d7-a678-5149ec588eb6@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <sxgXIbN2HShOSiuT5Da6QGaM8h5NlQqobad081pFZg4=.80c70a2c-c2bc-47d7-a678-5149ec588eb6@github.com>
Message-ID: <dUqyXjC7vsu2vZAZ7Vj_OD-6tGCcFGgExqtk4QJcSQs=.c3c983e2-a252-40b8-a810-e5e9ec47e223@github.com>

On Mon, 7 Mar 2022 17:09:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct caching test

Interesting fishing trip. DecimalFormatSymbols are mutable objects. As are NumberFormat/DecimalFormal. Hence, caching in the Formatter is the correct location.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Mon Mar  7 20:36:36 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 7 Mar 2022 20:36:36 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v7]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey has updated the pull request incrementally with four additional commits since the last revision:

 - Add comment about DecimalFormatSymbols being mutable objects.
 - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
   
   This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
 - Revert "Drop DecimalFormatSymbols.getLocale change"
   
   This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
 - Revert "Correct caching test"
   
   This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/bf797539..89354a0e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=05-06

  Stats: 34 lines in 2 files changed: 17 ins; 14 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From rriggs at openjdk.java.net  Mon Mar  7 21:29:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 7 Mar 2022 21:29:01 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v7]
In-Reply-To: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>
Message-ID: <I0ojhC7e0xOZW0ZEOWpgLH4gGyY8xgfn7mQZmveqnX0=.50636a83-4c9c-4090-9fe9-197adb2a9092@github.com>

On Mon, 7 Mar 2022 20:36:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add comment about DecimalFormatSymbols being mutable objects.
>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>    
>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>    
>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>  - Revert "Correct caching test"
>    
>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.

LGTM

src/java.base/share/classes/java/util/Formatter.java line 4550:

> 4548: 
> 4549:                 if (l == null || l.equals(Locale.US)) {
> 4550:                      grpSize = 3;

unintentional indentation

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7703

From duke at openjdk.java.net  Mon Mar  7 21:37:05 2022
From: duke at openjdk.java.net (Matteo Baccan)
Date: Mon, 7 Mar 2022 21:37:05 GMT
Subject: <i18n dev> Integrated: 8282657: Code cleanup: removing double
 semicolons at the end of lines
In-Reply-To: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
References: <lSnyimLiKkvJxYaX3R2Y2fCz70BqOEWzJmJ0CpwbxxI=.0a259879-2c23-4f24-a0f7-336e13e76269@github.com>
Message-ID: <IOsP6dA-9UbtLKUQwfdQE9Z6Lc6qO2iUIy_8Ywsk4Z0=.cbc4836e-3973-4cb3-bdb6-c413368ce9f5@github.com>

On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan <duke at openjdk.java.net> wrote:

> Hi
> 
> I have reviewed the code for removing double semicolons at the end of lines
> 
> all the best
> matteo

This pull request has now been integrated.

Changeset: ccad3923
Author:    Matteo Baccan <matteo.baccan at gmail.com>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ccad39237ab860c5c5579537f740177e3f1adcc9
Stats:     93 lines in 82 files changed: 0 ins; 0 del; 93 mod

8282657: Code cleanup: removing double semicolons at the end of lines

Reviewed-by: lancea, rriggs, ihse, prr, iris, wetmore, darcy, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/7268

From naoto at openjdk.java.net  Mon Mar  7 21:52:04 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 7 Mar 2022 21:52:04 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v7]
In-Reply-To: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>
Message-ID: <DMRuIrJ8iP73iq9M8sYU5O0rl-PhnL-dRLD0TExmNn0=.8a48384f-2701-4f47-a570-14c1bdf84bd4@github.com>

On Mon, 7 Mar 2022 20:36:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add comment about DecimalFormatSymbols being mutable objects.
>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>    
>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>    
>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>  - Revert "Correct caching test"
>    
>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.

Looks good. Since you are adding a new API, I would expect some unit tests for `DecimalFormatSymbols.getLocale()` method.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jpai at openjdk.java.net  Tue Mar  8 05:05:05 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 8 Mar 2022 05:05:05 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v7]
In-Reply-To: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>
Message-ID: <bUXtQdLGNqKIbxyRcMpYA8576-7RQY2nUzCRC6QVkEI=.1ca672c3-5792-4ea9-a361-b9e08c55d424@github.com>

On Mon, 7 Mar 2022 20:36:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Add comment about DecimalFormatSymbols being mutable objects.
>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>    
>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>    
>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>  - Revert "Correct caching test"
>    
>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.

src/java.base/share/classes/java/util/Formatter.java line 2019:

> 2017:             return dfs;
> 2018:         }
> 2019:         // Fetch a new local instance of DecimalFormatSymbols. Note that DFS are mutatble

Thank you Jim for these comments about multi-threaded access. Looks good to me.
One minor typo on this line - "mutatble" should have been "mutable".

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Tue Mar  8 13:09:36 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 8 Mar 2022 13:09:36 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v8]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <n_oCufKAsMAcallARs_hmqZq1kXmNUXuAbGTrX6sgbU=.dbbdea3e-a8a6-4fac-9a62-c13ceef19cbf@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add unit test for DecimalFormatSymbols.getLocale()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/89354a0e..d1879a7a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=06-07

  Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Tue Mar  8 13:19:39 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 8 Mar 2022 13:19:39 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v9]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Correct indentation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/d1879a7a..dfcc1ec2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Tue Mar  8 13:19:42 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 8 Mar 2022 13:19:42 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v7]
In-Reply-To: <bUXtQdLGNqKIbxyRcMpYA8576-7RQY2nUzCRC6QVkEI=.1ca672c3-5792-4ea9-a361-b9e08c55d424@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>
 <bUXtQdLGNqKIbxyRcMpYA8576-7RQY2nUzCRC6QVkEI=.1ca672c3-5792-4ea9-a361-b9e08c55d424@github.com>
Message-ID: <AzDEHHd3sjEMCEiL8H1sQgH4Q5qjxh7o06JkTbfnGaw=.97a6c626-e697-4144-8898-a5a1dcb24035@github.com>

On Tue, 8 Mar 2022 05:01:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add comment about DecimalFormatSymbols being mutable objects.
>>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>>    
>>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>>    
>>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>>  - Revert "Correct caching test"
>>    
>>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
>
> src/java.base/share/classes/java/util/Formatter.java line 2019:
> 
>> 2017:             return dfs;
>> 2018:         }
>> 2019:         // Fetch a new local instance of DecimalFormatSymbols. Note that DFS are mutatble
> 
> Thank you Jim for these comments about multi-threaded access. Looks good to me.
> One minor typo on this line - "mutatble" should have been "mutable".

Noted

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Tue Mar  8 13:19:44 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 8 Mar 2022 13:19:44 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v7]
In-Reply-To: <I0ojhC7e0xOZW0ZEOWpgLH4gGyY8xgfn7mQZmveqnX0=.50636a83-4c9c-4090-9fe9-197adb2a9092@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com>
 <I0ojhC7e0xOZW0ZEOWpgLH4gGyY8xgfn7mQZmveqnX0=.50636a83-4c9c-4090-9fe9-197adb2a9092@github.com>
Message-ID: <0HER9ZjhBSGPwEVG5ztPz9Uxk3lPxWbs2c3IFtxsboo=.890bd855-4c76-4fea-9596-a31bd92625df@github.com>

On Mon, 7 Mar 2022 21:24:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Add comment about DecimalFormatSymbols being mutable objects.
>>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>>    
>>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>>    
>>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>>  - Revert "Correct caching test"
>>    
>>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
>
> src/java.base/share/classes/java/util/Formatter.java line 4550:
> 
>> 4548: 
>> 4549:                 if (l == null || l.equals(Locale.US)) {
>> 4550:                      grpSize = 3;
> 
> unintentional indentation

Noted

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From ihse at openjdk.java.net  Tue Mar  8 14:08:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Mar 2022 14:08:10 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame [v4]
In-Reply-To: <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
 <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com>
Message-ID: <bEeOva48c_1Ko5G3Z0fN6B3zyla4n8156bjmKFmAeHU=.e60cc774-b1a8-4569-9a2f-b7e6a4009d39@github.com>

On Thu, 3 Mar 2022 16:55:46 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
>> 
>> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
>> 
>>         final ClassLoader loader = (caller != null) ?
>>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
>> 
>> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
>> 
>> The javadoc was updated for the caller sensitive methods changed.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more suggested changes

Build changes look good. Can't say anything about the rest.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7663

From naoto at openjdk.java.net  Tue Mar  8 17:11:10 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 8 Mar 2022 17:11:10 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v9]
In-Reply-To: <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com>
Message-ID: <DMURJ7uXblHflXLl3soBp9mYJCBzNsVhqAnVNy4SBqk=.6756f959-3395-428f-94c2-79ab1f448c02@github.com>

On Tue, 8 Mar 2022 13:19:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct indentation

Looks good. Thanks for adding the tests.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7703

From rriggs at openjdk.java.net  Tue Mar  8 17:22:10 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 8 Mar 2022 17:22:10 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v9]
In-Reply-To: <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com>
Message-ID: <OnHCBj6vfsRTTMP4lEH-uqR-k68hcnpKmegLLNzwfDw=.d80f4f11-8223-4547-956c-d5c83c5c8a98@github.com>

On Tue, 8 Mar 2022 13:19:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct indentation

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From duke at openjdk.java.net  Wed Mar  9 02:05:44 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 9 Mar 2022 02:05:44 GMT
Subject: <i18n dev> RFR: JDK-8280902 ResourceBundle::getBundle may throw
 NPE when invoked by JNI code with no caller frame [v5]
In-Reply-To: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
Message-ID: <1A3_6fwGH0K81xA_SzoIijntQnnHHoC1BRb6s3lrRgs=.064e9d34-edc6-4da9-95b6-72a3f452dd3d@github.com>

> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
> 
>         final ClassLoader loader = (caller != null) ?
>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

Tim Prinzing 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 seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8280902
 - remove unnecessary variable
 - more suggested changes
 - suggested changes
 - Update src/java.base/share/classes/java/util/ResourceBundle.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Use the unnamed module defined to the system class loader instead of the
   boot class loader.
 - JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7663/files
  - new: https://git.openjdk.java.net/jdk/pull/7663/files/45f9b37b..6600e1f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=03-04

  Stats: 17900 lines in 516 files changed: 12667 ins; 3251 del; 1982 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663

PR: https://git.openjdk.java.net/jdk/pull/7663

From duke at openjdk.java.net  Wed Mar  9 04:07:11 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 9 Mar 2022 04:07:11 GMT
Subject: <i18n dev> Integrated: JDK-8280902 ResourceBundle::getBundle may
 throw NPE when invoked by JNI code with no caller frame
In-Reply-To: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
References: <n5fs30pA4SpFIlFzNY0Vpe0MDw93dhCdr4cPfl8k0Hs=.4b9454d9-0372-4d83-ae52-af85c8168704@github.com>
Message-ID: <clDMGs3O6npS0VHVw699f8YNiPzACsl6S3RBa-QFfDg=.500b0bed-646a-4476-934a-4f788d9b6c02@github.com>

On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null.
> 
> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method:
> 
>         final ClassLoader loader = (caller != null) ?
>                 caller.getClassLoader() : getLoader(getCallerModule(caller));
> 
> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache.
> 
> The javadoc was updated for the caller sensitive methods changed.

This pull request has now been integrated.

Changeset: 31ad80a2
Author:    Tim Prinzing <tim.prinzing at oracle.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/31ad80a229e3f67823ff8f1fc914c5503f184b57
Stats:     218 lines in 4 files changed: 207 ins; 3 del; 8 mod

8280902: ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame

Reviewed-by: naoto, mchung, ihse

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

PR: https://git.openjdk.java.net/jdk/pull/7663

From achung at openjdk.java.net  Wed Mar  9 21:16:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 9 Mar 2022 21:16:48 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
Message-ID: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>

msg drop for jdk19, Mar 9, 2022

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

Commit messages:
 - open jdk19 l10n msg drop

Changes: https://git.openjdk.java.net/jdk/pull/7765/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280400
  Stats: 13775 lines in 142 files changed: 12170 ins; 1249 del; 356 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Wed Mar  9 22:29:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 9 Mar 2022 22:29:44 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <PBk3nk8e8eclzDy8yKIrJOgKLqveAK3NoSqrAzra6fg=.3dbfe55e-2394-4ee6-bd3b-43b558c02ef7@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

`src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties`
`src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties`

These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging).

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From joehw at openjdk.java.net  Thu Mar 10 00:46:44 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 10 Mar 2022 00:46:44 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <8oYKi_L4IgNDFUfJ9uXlSl47KULO4j1HudfJg3kVeCU=.90fa019e-8b6f-4a69-870b-cd53c8802490@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

For the bundles in java.xml:

For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date.

For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. 

For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header.

In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From dfuchs at openjdk.java.net  Thu Mar 10 10:34:43 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 10:34:43 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <p1RcBIafcDBf0k6FeY60oiHc94CG5wc5mJMDaNAO7js=.1bce7a1c-81cd-475d-bcbb-4423a5040b6b@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

For simple webserver resource files - should the copyright year be 2022?

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From zgu at openjdk.java.net  Thu Mar 10 13:39:04 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 10 Mar 2022 13:39:04 GMT
Subject: <i18n dev> RFR: 8282897: Fix call parameter to GetStringChars() in
 HostLocaleProviderAdapter_md.c
Message-ID: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>

Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a  `jboolean*`, instead of `jboolean`

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

Commit messages:
 - 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c

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

PR: https://git.openjdk.java.net/jdk/pull/7775

From shade at openjdk.java.net  Thu Mar 10 15:31:44 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 10 Mar 2022 15:31:44 GMT
Subject: <i18n dev> RFR: 8282897: Fix call parameter to GetStringChars()
 in HostLocaleProviderAdapter_md.c
In-Reply-To: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>
References: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>
Message-ID: <kkTyJezt0_ygOdK5za_oA7UNphpAohv1LY-Kwz_ak5M=.b86a59ba-ae21-443e-b76b-210f27c4eeaf@github.com>

On Thu, 10 Mar 2022 13:33:05 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a  `jboolean*`, instead of `jboolean`

Looks fine to me.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7775

From zgu at openjdk.java.net  Thu Mar 10 16:42:45 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 10 Mar 2022 16:42:45 GMT
Subject: <i18n dev> RFR: 8282897: Fix call parameter to GetStringChars()
 in HostLocaleProviderAdapter_md.c
In-Reply-To: <kkTyJezt0_ygOdK5za_oA7UNphpAohv1LY-Kwz_ak5M=.b86a59ba-ae21-443e-b76b-210f27c4eeaf@github.com>
References: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>
 <kkTyJezt0_ygOdK5za_oA7UNphpAohv1LY-Kwz_ak5M=.b86a59ba-ae21-443e-b76b-210f27c4eeaf@github.com>
Message-ID: <SO5ueQ1QTPAYbCh1yduToBsUifmyfpeOAx1k8D8o0GM=.61163e0e-3137-4de9-b993-b663a450f70f@github.com>

On Thu, 10 Mar 2022 15:28:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks fine to me.

Thanks, @shipilev

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

PR: https://git.openjdk.java.net/jdk/pull/7775

From naoto at openjdk.java.net  Thu Mar 10 17:03:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 17:03:45 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From dfuchs at openjdk.java.net  Thu Mar 10 17:09:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Mar 2022 17:09:44 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <TdJhSkQwWvukmhDKrxi5K9E0-pzh1UxqBFSKi0a1r18=.3eb1eada-4b4e-4856-85df-a1c7d04f92ed@github.com>
Message-ID: <eFN7SFB4835Ai-NMuO6yzfs0cdy5aM90VdU3qr7ctpQ=.52d046e1-33b6-407f-905f-1ca762f286d7@github.com>

On Thu, 10 Mar 2022 17:00:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment.

Thanks Naoto! I have no objection then.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Thu Mar 10 17:28:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 17:28:45 GMT
Subject: <i18n dev> RFR: 8282897: Fix call parameter to GetStringChars()
 in HostLocaleProviderAdapter_md.c
In-Reply-To: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>
References: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>
Message-ID: <6N80WM128ttYyb08HpsuHpvlU6ejKa3n7LzY8i6JyyQ=.f8341776-a00b-49a3-a343-8cc844185564@github.com>

On Thu, 10 Mar 2022 13:33:05 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a  `jboolean*`, instead of `jboolean`

LGTM. Thanks for the fix!

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7775

From achung at openjdk.java.net  Thu Mar 10 17:55:44 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Thu, 10 Mar 2022 17:55:44 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  moved CurrencyNames changes to jdk.localedata

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/fb51cf60..4735722d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00-01

  Stats: 2807 lines in 6 files changed: 693 ins; 1527 del; 587 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

From zgu at openjdk.java.net  Thu Mar 10 18:27:41 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 10 Mar 2022 18:27:41 GMT
Subject: <i18n dev> RFR: 8282897: Fix call parameter to GetStringChars()
 in HostLocaleProviderAdapter_md.c
In-Reply-To: <6N80WM128ttYyb08HpsuHpvlU6ejKa3n7LzY8i6JyyQ=.f8341776-a00b-49a3-a343-8cc844185564@github.com>
References: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>
 <6N80WM128ttYyb08HpsuHpvlU6ejKa3n7LzY8i6JyyQ=.f8341776-a00b-49a3-a343-8cc844185564@github.com>
Message-ID: <HYMBwk0em8jKdNzU6eqwfWETHwdPYHGTCO77nsz3Gb8=.7db99502-e591-48e3-9c58-f9fcd9810bc6@github.com>

On Thu, 10 Mar 2022 17:25:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> LGTM. Thanks for the fix!

Thanks for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/7775

From zgu at openjdk.java.net  Thu Mar 10 18:27:42 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 10 Mar 2022 18:27:42 GMT
Subject: <i18n dev> Integrated: 8282897: Fix call parameter to
 GetStringChars() in HostLocaleProviderAdapter_md.c
In-Reply-To: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>
References: <Z3UJvieD7OGywjTWmYfD_4SIikP_OpWaKJVWrbd5_YY=.a7517787-1e64-4e63-832b-dad4806ba776@github.com>
Message-ID: <gi1B5TZJYPD1soBWGhIWJ9c786NRF3zEBTJXvgDQ9oc=.f5b93169-e64f-4d09-aba9-d41df8fd2fc6@github.com>

On Thu, 10 Mar 2022 13:33:05 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a  `jboolean*`, instead of `jboolean`

This pull request has now been integrated.

Changeset: 879b6445
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/879b6445e33ad3a07461d01ea8f28a09979a4313
Stats:     19 lines in 1 file changed: 0 ins; 0 del; 19 mod

8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c

Reviewed-by: shade, naoto

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

PR: https://git.openjdk.java.net/jdk/pull/7775

From jlaskey at openjdk.java.net  Thu Mar 10 18:34:27 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 10 Mar 2022 18:34:27 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v10]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey 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 'master' into 8282625
 - Correct indentation
 - Add unit test for DecimalFormatSymbols.getLocale()
 - Add comment about DecimalFormatSymbols being mutable objects.
 - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
   
   This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
 - Revert "Drop DecimalFormatSymbols.getLocale change"
   
   This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
 - Revert "Correct caching test"
   
   This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
 - Correct caching test
 - Drop DecimalFormatSymbols.getLocale change
 - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation.
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/f239354a...84fa1fe7

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/dfcc1ec2..84fa1fe7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=08-09

  Stats: 7713 lines in 305 files changed: 5264 ins; 679 del; 1770 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From zgu at openjdk.java.net  Thu Mar 10 18:47:04 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 10 Mar 2022 18:47:04 GMT
Subject: <i18n dev> RFR: 8282887: Potential memory leak in
 sun.util.locale.provider.HostLocalProviderAdapterImpl.getNumberPattern() on
 Windows
Message-ID: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>

Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`.

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

Commit messages:
 - 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

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

PR: https://git.openjdk.java.net/jdk/pull/7777

From cjplummer at openjdk.java.net  Thu Mar 10 19:06:43 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 10 Mar 2022 19:06:43 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 305:

> 303:         {"Thread not suspended", "Thread nicht unterbrochen"},
> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
> 305:         {"Threadgroup name not specified.", "Name der Threadgruppe nicht angegeben."},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 342:

> 340:         {"watch modification of", "\u00C4nderung von {0}.{1} \u00FCberwachen"},
> 341:         {"zz help text",
> 342:              "** Befehlsliste **\nconnectors                -- Listet verf\u00FCgbare Connectors und Transporte in dieser VM auf\n\nrun [class [args]]        -- Startet die Ausf\u00FChrung der Hauptklasse der Anwendung\n\nthreads [threadgroup]     -- Listet Threads auf\nthread <Thread-ID>        -- Legt den Standardthread fest\nsuspend [thread id(s)]    -- Unterbricht Threads (Standard: all)\nresume [thread id(s)]    -- Nimmt Threads wieder auf (Standard: all)\nwhere [<Thread-ID> | all] -- Gibt den Stack eines Threads aus\nwherei [<Thread-ID> | all] -- Gibt den Stack eines Threads mit PC-Informationen aus\nup [n frames]             -- Verschiebt den Stack eines Threads nach oben\ndown [n frames]             -- Verschiebt den Stack eines Threads nach unten\nkill <Thread-ID> <Ausdruck>   -- Bricht einen Thread mit dem angegebenen Ausnahmeobjekt ab\ninterrupt <Thread-ID>     -- Unterbricht einen Thread\n\nprint <Ausdruck>              -- Gibt den Wert eines Ausdrucks aus\ndump <A
 usdruck>               -- Gibt alle Objektinformationen aus\neval <Ausdruck>               -- Bewertet einen Ausdruck (wie \"print\")\nset <lvalue> = <Ausdruck>     -- Weist einem Feld/einer Variablen/einem Arrayelement einen neuen Wert zu\nlocals                    -- Gibt alle lokalen Variablen im aktuellen Stackframe aus\n\nclasses                   -- Listet derzeit bekannte Klassen auf\nclass <Klassen-ID>          -- Zeigt Details einer benannten Klasse an\nmethods <Klassen-ID>        -- Listet die Methoden einer Klasse auf\nfields <Klassen-ID>        -- Listet die Felder einer Klasse auf\n\nthreadgroups              -- Listet Threadgruppen auf\nthreadgroup <Name>        -- Legt die aktuelle Threadgruppe fest\n\nstop [go|thread] [<thread_id>] <at|in> <Position>\n                          -- Legt einen Breakpoint fest\n                          -- Wenn Sie keine Optionen angeben, wird die aktuelle Breakpoint-Liste ausgegeben\n                          -- Wenn Sie \"go\" angeben,
  wird der Vorgang nach dem Stoppen sofort wiederaufgenommen\n                          -- Wenn Sie \"thread\" angeben, wird nur der Thread unterbrochen, in dem gestoppt wurde\n                          -- Wenn Sie weder \"go\" noch \"thread\" angeben, werden alle Threads unterbrochen\n                          -- Wenn Sie eine ganzzahlige <thread_id> angeben, wird der Vorgang nur im angegebenen Thread gestoppt\n                          -- \"at\" und \"in\" haben die gleiche Bedeutung\n                          -- <Position> kann eine Zeilennummer oder eine Methode sein:\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<Methode>[(argument_type,...)]\nclear <class id>.<Methode>[(argument_type,...)]\n                          -- L\u00F6scht einen Breakpoint in einer Methode\nclear <Klassen-ID>:<Zeile>   -- L\u00F6scht einen Breakpoint bei einer Zeile\nclear                     -- Listet Breakpoints auf\ncatch [uncaught|caught|all] <Kl
 assen-ID>|<Klassenmuster>\n                          -- Break bei der angegebenen Ausnahme\nignore [uncaught|caught|all] <Klassen-ID>|<Klassenmuster>\n                          -- Bricht \"catch\" f\u00FCr die angegebene Ausnahme ab\nwatch [access|all] <Klassen-ID>.<Feldname>\n                          -- \u00DCberwacht Zugriffe/\u00C4nderungen eines Feldes\nunwatch [access|all] <Klassen-ID>.<Feldname>\n                          -- Hebt die \u00DCberwachung der Zugriffe/\u00C4nderungen eines Feldes auf\ntrace [go] methods [thread]\n                          -- Verfolgt Methodenstarts und -beendigungen.\n                          -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\ntrace [go] method exit | exits [thread]\n                          -- Verfolgt die Beendigung der aktuellen Methode oder die Beendigungen aller Methoden\n                          -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\nuntrace [methods]         -- Stoppt 
 das Tracing von Methodenstarts und/oder -beendigungen\nstep                      -- F\u00FChrt die aktuelle Zeile aus\nstep up                   -- Ausf\u00FChren, bis die aktuelle Methode an den Aufrufer zur\u00FCckgegeben wird\nstepi                     -- F\u00FChrt die aktuelle Anweisung aus\nnext                      -- Eine Zeile weiter (Aufrufe auslassen)\ncont                      -- Setzt die Ausf\u00FChrung ab dem Breakpoint fort\n\nlist [line number|method] -- Gibt den Quellcode aus\nuse (or sourcepath) [source file path]\n                          -- Zeigt den Quellpfad an oder \u00E4ndert diesen\nexclude [<Klassenmuster>, ... | \"none\"]\n                          -- Meldet keine Schritt- oder Methodenereignisse f\u00FCr angegebene Klassen\nclasspath                 -- Gibt Classpath-Informationen aus der Ziel-VM aus\n\nmonitor <Befehl>         -- F\u00FChrt bei jedem Programmstopp einen Befehl aus\nmonitor                   -- Listet Monitore auf\nunmonitor <Monitornum
 mer>      -- L\u00F6scht einen Monitor\nread <Dateiname>           -- Liest eine Befehlsdatei und f\u00FChrt diese aus\n\nlock <Ausdruck>               -- Gibt Sperrinformationen f\u00FCr ein Objekt aus\nthreadlocks [thread id]   -- Gibt Sperrinformationen f\u00FCr einen Thread aus\n\npop                       -- Holt den Stack bis zum aktuellen Frame (einschlie\u00DFlich)\nreenter                   -- Wie \"pop\", aber der aktuelle Frame wird wieder eingegeben\nredefine <Klassen-ID> <Klassendateiname>\n                          -- Definiert den Code f\u00FCr eine Klasse neu\n\ndisablegc <Ausdruck>          -- Verhindert die Garbage Collection eines Objekts\nenablegc <Ausdruck>          -- L\u00E4sst die Garbage Collection eines Objekts zu\n\n!!                        -- Wiederholt den letzten Befehl\n<n> <Befehl>             -- Wiederholt einen Befehl n-mal\nrepeat                    -- Zeigt an, ob die Wiederholung durch leeren Befehl im GDB-Stil aktiviert ist\nrepeat <on|off>    
        -- Aktiviert/deaktiviert die Wiederholung im GDB-Stil\n# <Befehl>               -- Verwerfen (kein Vorgang)\nhelp (oder ?)               -- Listet Befehle auf\ndbgtrace [flag]           -- Identisch mit der Befehlszeilenoption \"dbgtrace\"\nversion                   -- Gibt Versionsinformationen aus\nexit (oder quit)            -- Beendet den Debugger\n\n<Klassen-ID>: Ein vollst\u00E4ndiger Klassenname mit Package-Qualifiers\n<Klassenmuster>: Ein Klassenname mit einem Platzhalter am Anfang oder Ende (\"*\")\n<Thread-ID>: Threadnummer aus dem Befehl \"threads\"\n<Ausdruck>: Ein Ausdruck der Java(TM)-Programmiersprache.\nDer Gro\u00DFteil der g\u00E4ngigen Syntax wird unterst\u00FCtzt.\n\nStartbefehle k\u00F6nnen in \"jdb.ini\" oder \".jdbrc\" abgelegt werden\nin user.home oder user.dir"},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305:

> 303:         {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
> 305:         {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},

I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 342:

> 340:         {"watch modification of", "{0}.{1}\u306E\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1"},
> 341:         {"zz help text",
> 342:              "** \u30B3\u30DE\u30F3\u30C9\u30FB\u30EA\u30B9\u30C8 **\nconnectors                -- \u3053\u306EVM\u5185\u306E\u4F7F\u7528\u53EF\u80FD\u306A\u30B3\u30CD\u30AF\u30BF\u3068\u30C8\u30E9\u30F3\u30B9\u30DD\u30FC\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\n\nrun [class [args]]        -- \u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u306E\u30E1\u30A4\u30F3\u30FB\u30AF\u30E9\u30B9\u306E\u5B9F\u884C\u3092\u958B\u59CB\u3057\u307E\u3059\n\nthreads [threadgroup]     -- \u30B9\u30EC\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthread <thread id>        -- \u30C7\u30D5\u30A9\u30EB\u30C8\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u8A2D\u5B9A\u3057\u307E\u3059\nsuspend [thread id(s)]    -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nresume [thread id(s)]     -- \u30B9\u30EC\u30C3\u30C9\u3092\u518D\u958B\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nwhere [<thread id> | all]
  -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30C0\u30F3\u30D7\u3057\u307E\u3059\nwherei [<thread id> | all]-- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092pc\u60C5\u5831\u3068\u3068\u3082\u306B\u30C0\u30F3\u30D7\u3057\u307E\u3059\nup [n frames]             -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0A\u306B\u79FB\u52D5\u3057\u307E\u3059\ndown [n frames]           -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0B\u306B\u79FB\u52D5\u3057\u307E\u3059\nkill <thread id> <expr>   -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u3067\u30B9\u30EC\u30C3\u30C9\u3092\u5F37\u5236\u7D42\u4E86\u3057\u307E\u3059\ninterrupt <thread id>     -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n\nprint <expr>              -- \u5F0F\u306E\u5024\u3092\u51FA\u529B\u3057\u307E\u3059\ndump <expr>               -- \u3059\u3079\u3066\u306E\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u60C5\u58
 31\u3092\u51FA\u529B\u3057\u307E\u3059\neval <expr>               -- \u5F0F\u3092\u8A55\u4FA1\u3057\u307E\u3059(print\u3068\u540C\u3058)\nset <lvalue> = <expr>     -- \u65B0\u3057\u3044\u5024\u3092\u30D5\u30A3\u30FC\u30EB\u30C9/\u5909\u6570/\u914D\u5217\u8981\u7D20\u306B\u4EE3\u5165\u3057\u307E\u3059\nlocals                    -- \u73FE\u5728\u306E\u30B9\u30BF\u30C3\u30AF\u30FB\u30D5\u30EC\u30FC\u30E0\u5185\u306E\u3059\u3079\u3066\u306E\u30ED\u30FC\u30AB\u30EB\u5909\u6570\u3092\u51FA\u529B\u3057\u307E\u3059\n\nclasses                   -- \u73FE\u5728\u65E2\u77E5\u306E\u30AF\u30E9\u30B9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nclass <class id>          -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u8A73\u7D30\u3092\u8868\u793A\u3057\u307E\u3059\nmethods <class id>        -- \u30AF\u30E9\u30B9\u306E\u30E1\u30BD\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nfields <class id>         -- \u30AF\u30E9\u30B9\u306E\u30D5\u30A3\u30FC\u30EB\u30C9\u3092\u30EA\u30B9\u30C8\u305
 7\u307E\u3059\n\nthreadgroups              -- \u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthreadgroup <name>        -- \u73FE\u5728\u306E\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n\nstop [go|thread] [<thread_id>] <at|in> <location>\n                          -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n                          -- \u30AA\u30D7\u30B7\u30E7\u30F3\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u306E\u73FE\u5728\u306E\u30EA\u30B9\u30C8\u304C\u51FA\u529B\u3055\u308C\u307E\u3059\n                          -- \"go\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u505C\u6B62\u5F8C\u3059\u3050\u306B\u518D\u958B\u3057\u307E\u3059\n                          -- \"thread\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\
 u505C\u6B62\u3057\u305F\u30B9\u30EC\u30C3\u30C9\u306E\u307F\u4E2D\u65AD\u3057\u307E\u3059\n                          -- \"go\"\u3082\"thread\"\u3082\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n                          -- \u6574\u6570\u306E<thread_id>\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u6307\u5B9A\u3055\u308C\u305F\u30B9\u30EC\u30C3\u30C9\u3067\u306E\u307F\u505C\u6B62\u3057\u307E\u3059\n                          -- \"at\"\u3068\"in\"\u306F\u540C\u3058\u610F\u5473\u3092\u6301\u3061\u307E\u3059\n                          -- <location>\u306F\u884C\u756A\u53F7\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u306B\u3059\u308B\u3053\u3068\u304C\u3067\u304D\u307E\u3059:\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<method>[(argument_type,...)]\nclear <class id>.<method>[(argument_type,...)]\n  
                         -- \u30E1\u30BD\u30C3\u30C9\u5185\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear <class id>:<line>   -- \u884C\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear                     -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\ncatch [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u304C\u767A\u751F\u3057\u305F\u3068\u304D\u306B\u30D6\u30EC\u30FC\u30AF\u3057\u307E\u3059\nignore [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u306E'catch'\u3092\u53D6\u308A\u6D88\u3057\u307E\u3059\nwatch [access|all] <class id>.<field name>\n                          -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u3092\u30A6\u3
 0A9\u30C3\u30C1\u3057\u307E\u3059\nunwatch [access|all] <class id>.<field name>\n                          -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1\u3092\u4E2D\u6B62\u3057\u307E\u3059\ntrace [go] methods [thread]\n                          -- \u30E1\u30BD\u30C3\u30C9\u306E\u5165\u308A\u53E3\u3068\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\u3002\n                          -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\ntrace [go] method exit | exits [thread]\n                          -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u307E\u305F\u306F\u3059\u3079\u3066\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\n                          -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\
 u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\nuntrace [methods]         -- \u30E1\u30BD\u30C3\u30C9\u306E\u958B\u59CB\u307E\u305F\u306F\u7D42\u4E86\u306E\u30C8\u30EC\u30FC\u30B9\u3092\u505C\u6B62\u3057\u307E\u3059\nstep                      -- \u73FE\u5728\u306E\u884C\u3092\u5B9F\u884C\u3057\u307E\u3059\nstep up                   -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u304C\u30E1\u30BD\u30C3\u30C9\u306E\u547C\u51FA\u3057\u5143\u306B\u623B\u308B\u307E\u3067\u5B9F\u884C\u3057\u307E\u3059\nstepi                     -- \u73FE\u5728\u306E\u547D\u4EE4\u3092\u5B9F\u884C\u3057\u307E\u3059\nnext                      -- 1\u884C\u3092\u30B9\u30C6\u30C3\u30D7\u5B9F\u884C\u3057\u307E\u3059(\u547C\u51FA\u3057\u3092\u30B9\u30C6\u30C3\u30D7\u30AA\u30FC\u30D0\u30FC)\ncont                      -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u304B\u3089\u5B9F\u884C\u3092\u7D9A\u884C\u3057\u307E\u3059\n\nlist [line number|method] -- \u30BD\u30FC\u30B9\u30FB\u30B3\u30FC\u30C9\u3092\u
 51FA\u529B\u3057\u307E\u3059\nuse (or sourcepath) [source file path]\n                          -- \u30BD\u30FC\u30B9\u30FB\u30D1\u30B9\u3092\u8868\u793A\u307E\u305F\u306F\u5909\u66F4\u3057\u307E\u3059\nexclude [<class pattern>, ... | \"none\"]\n                          -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u30B9\u30C6\u30C3\u30D7\u3084\u30E1\u30BD\u30C3\u30C9\u30FB\u30A4\u30D9\u30F3\u30C8\u3092\u5831\u544A\u3057\u307E\u305B\u3093\nclasspath                 -- \u30BF\u30FC\u30B2\u30C3\u30C8VM\u304B\u3089\u30AF\u30E9\u30B9\u30D1\u30B9\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\nmonitor <command>         -- \u30D7\u30ED\u30B0\u30E9\u30E0\u304C\u505C\u6B62\u3059\u308B\u305F\u3073\u306B\u30B3\u30DE\u30F3\u30C9\u3092\u5B9F\u884C\u3057\u307E\u3059\nmonitor                   -- \u30E2\u30CB\u30BF\u30FC\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nunmonitor <monitor#>      -- \u30E2\u30CB\u30BF\u30FC\u3092\u524A\u9664\u3057\u307E\u3059\nread <filename>           -- \u30B
 3\u30DE\u30F3\u30C9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u8AAD\u307F\u53D6\u3063\u3066\u5B9F\u884C\u3057\u307E\u3059\n\nlock <expr>               -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nthreadlocks [thread id]   -- \u30B9\u30EC\u30C3\u30C9\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\npop                       -- \u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u307E\u3067\u306E\u3059\u3079\u3066\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30DD\u30C3\u30D7\u3057\u307E\u3059\nreenter                   -- pop\u3068\u540C\u3058\u3067\u3059\u304C\u3001\u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u304C\u518D\u5165\u529B\u3055\u308C\u307E\u3059\nredefine <class id> <class file name>\n                          -- \u30AF\u30E9\u30B9\u306E\u30B3\u30FC\u30C9\u3092\u518D\u5B9A\u7FA9\u3057\u307E\u3059\n\ndisablegc <expr>          -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3
 \u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u6291\u5236\u3057\u307E\u3059\nenablegc <expr>           -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3\u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u8A31\u53EF\u3057\u307E\u3059\n\n!!                        -- \u6700\u5F8C\u306E\u30B3\u30DE\u30F3\u30C9\u3092\u7E70\u308A\u8FD4\u3057\u307E\u3059\n<n> <command>             -- \u30B3\u30DE\u30F3\u30C9\u3092n\u56DE\u7E70\u308A\u8FD4\u3057\u307E\u3059\nrepeat                    -- GDB\u5F62\u5F0F\u306E\u7A7A\u306E\u30B3\u30DE\u30F3\u30C9\u306E\u7E70\u8FD4\u3057\u304C\u6709\u52B9\u306B\u306A\u3063\u3066\u3044\u308B\u304B\u3069\u3046\u304B\u3092\u793A\u3057\u307E\u3059\nrepeat <on|off>           -- GDB\u5F62\u5F0F\u306E\u7E70\u8FD4\u3057\u3092\u6709\u52B9/\u7121\u52B9\u306B\u3057\u307E\u3059\n# <command>               -- \u7834\u68C4\u3057\u307E\u3059(\u64CD\u4F5C\u306A\u3057)\nhelp (\u307E\u305F\u306F?)               -- \u30B3\u30DE\u30F3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u3
 07E\u3059\ndbgtrace [flag]           -- dbgtrace\u30B3\u30DE\u30F3\u30C9\u30FB\u30E9\u30A4\u30F3\u30FB\u30AA\u30D7\u30B7\u30E7\u30F3\u3068\u540C\u3058\u3067\u3059\nversion                   -- \u30D0\u30FC\u30B8\u30E7\u30F3\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nexit (\u307E\u305F\u306Fquit)            -- \u30C7\u30D0\u30C3\u30AC\u3092\u7D42\u4E86\u3057\u307E\u3059\n\n<class id>: \u30D1\u30C3\u30B1\u30FC\u30B8\u4FEE\u98FE\u5B50\u3092\u542B\u3080\u5B8C\u5168\u30AF\u30E9\u30B9\u540D\n<class pattern>: \u5148\u982D\u307E\u305F\u306F\u672B\u5C3E\u306E\u30EF\u30A4\u30EB\u30C9\u30AB\u30FC\u30C9('*')\u3092\u542B\u3080\u30AF\u30E9\u30B9\u540D\n<thread id>: 'threads'\u30B3\u30DE\u30F3\u30C9\u3067\u5831\u544A\u3055\u308C\u308B\u30B9\u30EC\u30C3\u30C9\u756A\u53F7\n<expr>: Java(TM)\u30D7\u30ED\u30B0\u30E9\u30DF\u30F3\u30B0\u8A00\u8A9E\u306E\u5F0F\u3002\n\u307B\u3068\u3093\u3069\u306E\u4E00\u822C\u7684\u306A\u69CB\u6587\u304C\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u307E\u3059\u
 3002\n\n\u8D77\u52D5\u30B3\u30DE\u30F3\u30C9\u306F\u3001\"jdb.ini\"\u307E\u305F\u306F\".jdbrc\"\u306B\u914D\u7F6E\u3067\u304D\u307E\u3059\n(user.home\u307E\u305F\u306Fuser.dir\u5185)"},

Also as part of #7687 there is a new entry for the `threadgroup` command without any argument. This used to produce the "Threadgroup name not specified" error message which is I mentioned above was removed. It now has supported functionality, so there should be two `threadgroup` entries:

             "threadgroup <name>        -- set current threadgroup to <name>\n" +
             "threadgroup               -- set current threadgroup back to the top level threadgroup\n" +

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 305:

> 303:         {"Thread not suspended", "\u672A\u6302\u8D77\u7EBF\u7A0B"},
> 304:         {"thread group number description name", "{0,number,integer}\u3002{1} {2}"},
> 305:         {"Threadgroup name not specified.", "\u672A\u6307\u5B9A\u7EBF\u7A0B\u7EC4\u540D\u3002"},

Same comment here as mentioned in TTYResources_ja.java.

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 342:

> 340:         {"watch modification of", "\u76D1\u89C6{0}.{1}\u7684\u4FEE\u6539"},
> 341:         {"zz help text",
> 342:              "** \u547D\u4EE4\u5217\u8868 **\nconnectors                -- \u5217\u51FA\u6B64 VM \u4E2D\u53EF\u7528\u7684\u8FDE\u63A5\u5668\u548C\u4F20\u8F93\n\nrun [class [args]]        -- \u5F00\u59CB\u6267\u884C\u5E94\u7528\u7A0B\u5E8F\u7684\u4E3B\u7C7B\n\nthreads [threadgroup]     -- \u5217\u51FA\u7EBF\u7A0B\nthread <thread id>        -- \u8BBE\u7F6E\u9ED8\u8BA4\u7EBF\u7A0B\nsuspend [thread id(s)]    -- \u6302\u8D77\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nresume [thread id(s)]     -- \u6062\u590D\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nwhere [<thread id> | all] -- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808\nwherei [<thread id> | all]-- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808, \u4EE5\u53CA pc \u4FE1\u606F\nup [n frames]             -- \u4E0A\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\ndown [n frames]           -- \u4E0B\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\nkill <thread id> <expr>   -- \u7EC8\u6B62\u5177\u6709\u7ED9\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u5BF9\u8C61\u7684\u7EBF\u7A0B
 \ninterrupt <thread id>     -- \u4E2D\u65AD\u7EBF\u7A0B\n\nprint <expr>              -- \u8F93\u51FA\u8868\u8FBE\u5F0F\u7684\u503C\ndump <expr>               -- \u8F93\u51FA\u6240\u6709\u5BF9\u8C61\u4FE1\u606F\neval <expr>               -- \u5BF9\u8868\u8FBE\u5F0F\u6C42\u503C (\u4E0E print \u76F8\u540C)\nset <lvalue> = <expr>     -- \u5411\u5B57\u6BB5/\u53D8\u91CF/\u6570\u7EC4\u5143\u7D20\u5206\u914D\u65B0\u503C\nlocals                    -- \u8F93\u51FA\u5F53\u524D\u5806\u6808\u5E27\u4E2D\u7684\u6240\u6709\u672C\u5730\u53D8\u91CF\n\nclasses                   -- \u5217\u51FA\u5F53\u524D\u5DF2\u77E5\u7684\u7C7B\nclass <class id>          -- \u663E\u793A\u5DF2\u547D\u540D\u7C7B\u7684\u8BE6\u7EC6\u8D44\u6599\nmethods <class id>        -- \u5217\u51FA\u7C7B\u7684\u65B9\u6CD5\nfields <class id>         -- \u5217\u51FA\u7C7B\u7684\u5B57\u6BB5\n\nthreadgroups              -- \u5217\u51FA\u7EBF\u7A0B\u7EC4\nthreadgroup <name>        -- \u8BBE\u7F6E\u5F53\u524D\u7EBF\u7A0B\u7EC4\n\nstop [go|
 thread] [<thread_id>] <at|in> <location>\n                          -- \u8BBE\u7F6E\u65AD\u70B9\n                          -- \u5982\u679C\u672A\u63D0\u4F9B\u4EFB\u4F55\u9009\u9879\uFF0C\u5219\u5C06\u6253\u5370\u5F53\u524D\u65AD\u70B9\u5217\u8868\n                          -- \u5982\u679C\u6307\u5B9A \"go\"\uFF0C\u5219\u5728\u505C\u6B62\u540E\u7ACB\u5373\u6062\u590D\n                          -- \u5982\u679C\u6307\u5B9A \"thread\"\uFF0C\u5219\u4EC5\u6302\u8D77\u5728\u5176\u4E2D\u505C\u6B62\u7684\u7EBF\u7A0B\n                          -- \u5982\u679C\u65E2\u672A\u6307\u5B9A \"go\" \u4E5F\u672A\u6307\u5B9A \"thread\"\uFF0C\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\n                          -- \u5982\u679C\u6307\u5B9A\u4EE5\u6574\u6570\u8868\u793A\u7684 <thread_id>\uFF0C\u5219\u4EC5\u5728\u6307\u5B9A\u7684\u7EBF\u7A0B\u4E2D\u505C\u6B62\n                          -- \"at\" \u548C \"in\" \u7684\u542B\u4E49\u76F8\u540C\n                          -- <location> \u53EF\u4EE5\u662F\u884C\u53
 F7\u6216\u65B9\u6CD5\uFF1A\n                          --   <class_id>:<line_number>\n                          --   <class_id>.<method>[(argument_type,...)]\nclear <class id>.<method>[(argument_type,...)]\n                          -- \u6E05\u9664\u65B9\u6CD5\u4E2D\u7684\u65AD\u70B9\nclear <class id>:<line>   -- \u6E05\u9664\u884C\u4E2D\u7684\u65AD\u70B9\nclear                     -- \u5217\u51FA\u65AD\u70B9\ncatch [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u51FA\u73B0\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u65F6\u4E2D\u65AD\nignore [uncaught|caught|all] <class id>|<class pattern>\n                          -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF, \u53D6\u6D88 'catch'\nwatch [access|all] <class id>.<field name>\n                          -- \u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u8BBF\u95EE/\u4FEE\u6539\nunwatch [access|all] <class id>.<field name>\n                          -- \u505C\u6B62\u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u
 8BBF\u95EE/\u4FEE\u6539\ntrace [go] methods [thread]\n                          -- \u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C\u9000\u51FA\u3002\n                          -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\ntrace [go] method exit | exits [thread]\n                          -- \u8DDF\u8E2A\u5F53\u524D\u65B9\u6CD5\u7684\u9000\u51FA, \u6216\u8005\u6240\u6709\u65B9\u6CD5\u7684\u9000\u51FA\n                          -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\nuntrace [methods]         -- \u505C\u6B62\u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C/\u6216\u9000\u51FA\nstep                      -- \u6267\u884C\u5F53\u524D\u884C\nstep up                   -- \u4E00\u76F4\u6267\u884C, \u76F4\u5230\u5F53\u524D\u65B9\u6CD5\u8FD4\u56DE\u5230\u5176\u8C03\u7528\u65B9\nstepi                     -- \u6267\u884C\u5F53\u524D\u6307\u4EE4\n\u4E0B\u4E00\u6B65                      -- \u6B65\u8FDB\u4E00\u884C (\u6B65\u8FC7\u
 8C03\u7528)\ncont                      -- \u4ECE\u65AD\u70B9\u5904\u7EE7\u7EED\u6267\u884C\n\nlist [line number|method] -- \u8F93\u51FA\u6E90\u4EE3\u7801\nuse (\u6216 sourcepath) [source file path]\n                          -- \u663E\u793A\u6216\u66F4\u6539\u6E90\u8DEF\u5F84\nexclude [<class pattern>, ... | \"none\"]\n                          -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u7C7B, \u4E0D\u62A5\u544A\u6B65\u9AA4\u6216\u65B9\u6CD5\u4E8B\u4EF6\nclasspath                 -- \u4ECE\u76EE\u6807 VM \u8F93\u51FA\u7C7B\u8DEF\u5F84\u4FE1\u606F\n\nmonitor <command>         -- \u6BCF\u6B21\u7A0B\u5E8F\u505C\u6B62\u65F6\u6267\u884C\u547D\u4EE4\nmonitor                   -- \u5217\u51FA\u76D1\u89C6\u5668\nunmonitor <monitor#>      -- \u5220\u9664\u76D1\u89C6\u5668\nread <filename>           -- \u8BFB\u53D6\u5E76\u6267\u884C\u547D\u4EE4\u6587\u4EF6\n\nlock <expr>               -- \u8F93\u51FA\u5BF9\u8C61\u7684\u9501\u4FE1\u606F\nthreadlocks [thread id]   -- \u8F93\u51FA\u7EBF\u7A0B\u7684\u9501
 \u4FE1\u606F\n\npop                       -- \u901A\u8FC7\u5F53\u524D\u5E27\u51FA\u6808, \u4E14\u5305\u542B\u5F53\u524D\u5E27\nreenter                   -- \u4E0E pop \u76F8\u540C, \u4F46\u91CD\u65B0\u8FDB\u5165\u5F53\u524D\u5E27\nredefine <class id> <class file name>\n                          -- \u91CD\u65B0\u5B9A\u4E49\u7C7B\u7684\u4EE3\u7801\n\ndisablegc <expr>          -- \u7981\u6B62\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\nenablegc <expr>           -- \u5141\u8BB8\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\n\n!!                        -- \u91CD\u590D\u6267\u884C\u6700\u540E\u4E00\u4E2A\u547D\u4EE4\n<n> <command>             -- \u5C06\u547D\u4EE4\u91CD\u590D\u6267\u884C n \u6B21\nrepeat                    -- \u663E\u793A\u662F\u5426\u542F\u7528\u4E86 GDB \u6837\u5F0F\u7684\u7A7A\u547D\u4EE4\u91CD\u590D\nrepeat <on|off>           -- \u542F\u7528/\u7981\u7528 GDB \u6837\u5F0F\u7684\u91CD\u590D\n# <command>               -- \u653E\u5F03 (\u65E0\u64CD\u4F5C)\nhelp (\u6216 ?)     
           -- \u5217\u51FA\u547D\u4EE4\ndbgtrace [flag]           -- \u4E0E dbgtrace \u547D\u4EE4\u884C\u9009\u9879\u76F8\u540C\nversion                   -- \u8F93\u51FA\u7248\u672C\u4FE1\u606F\nexit (\u6216 quit)            -- \u9000\u51FA\u8C03\u8BD5\u5668\n\n<class id>: \u5E26\u6709\u7A0B\u5E8F\u5305\u9650\u5B9A\u7B26\u7684\u5B8C\u6574\u7C7B\u540D\n<class pattern>: \u5E26\u6709\u524D\u5BFC\u6216\u5C3E\u968F\u901A\u914D\u7B26 ('*') \u7684\u7C7B\u540D\n<thread id>: 'threads' \u547D\u4EE4\u4E2D\u62A5\u544A\u7684\u7EBF\u7A0B\u7F16\u53F7\n<expr>: Java(TM) \u7F16\u7A0B\u8BED\u8A00\u8868\u8FBE\u5F0F\u3002\n\u652F\u6301\u5927\u591A\u6570\u5E38\u89C1\u8BED\u6CD5\u3002\n\n\u53EF\u4EE5\u5C06\u542F\u52A8\u547D\u4EE4\u7F6E\u4E8E \"jdb.ini\" \u6216 \".jdbrc\" \u4E2D\n\u4F4D\u4E8E user.home \u6216 user.dir \u4E2D"},

Same comment here as mentioned in TTYResources_ja.java.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Thu Mar 10 19:49:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 19:49:44 GMT
Subject: <i18n dev> RFR: 8282887: Potential memory leak in
 sun.util.locale.provider.HostLocalProviderAdapterImpl.getNumberPattern() on
 Windows
In-Reply-To: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
References: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
Message-ID: <s8ACRwWINelpYUK26aJSbIRXOLnxAsbyp2cxf1gVhjo=.09e42276-db78-4442-85c6-48f5c7d18cc4@github.com>

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`.

LGTM.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7777

From naoto at openjdk.java.net  Thu Mar 10 19:54:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Mar 2022 19:54:44 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <oMFrgMwp9G7NK7ODUrjTKrPIFUgFnperV1nrSzNBU_A=.4014965c-a571-40a9-8ed2-40559c24fadb@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

No need for these lines in each localized files, as English bundle contains them.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

Same here with `de` bundle.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

and here.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From rriggs at openjdk.java.net  Thu Mar 10 22:47:46 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 10 Mar 2022 22:47:46 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v10]
In-Reply-To: <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>
Message-ID: <2_PPLf9un51N9nJZ-lBi6NsSw8k1ZguLVQGEGm3Lsb0=.cdd3a8d6-9c4f-4393-8fa4-1411372593a5@github.com>

On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey 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 'master' into 8282625
>  - Correct indentation
>  - Add unit test for DecimalFormatSymbols.getLocale()
>  - Add comment about DecimalFormatSymbols being mutable objects.
>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>    
>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>    
>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>  - Revert "Correct caching test"
>    
>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
>  - Correct caching test
>  - Drop DecimalFormatSymbols.getLocale change
>  - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation.
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/59f5719e...84fa1fe7

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jpai at openjdk.java.net  Fri Mar 11 04:31:13 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 04:31:13 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v10]
In-Reply-To: <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>
Message-ID: <nk2sk9xm2MhASMPhc1RIgBmZdEq0bH8vQhij5bvntZI=.d5bad08a-55ce-48ac-86e9-c73417f5cdf3@github.com>

On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey 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 'master' into 8282625
>  - Correct indentation
>  - Add unit test for DecimalFormatSymbols.getLocale()
>  - Add comment about DecimalFormatSymbols being mutable objects.
>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>    
>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>    
>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>  - Revert "Correct caching test"
>    
>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
>  - Correct caching test
>  - Drop DecimalFormatSymbols.getLocale change
>  - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation.
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/11e9685d...84fa1fe7

src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192:

> 190: 
> 191:     /**
> 192:      * {@return locale used to create this instance}

Hello Jim, the opening and closing `{`, I think aren't needed for a `@return`

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Fri Mar 11 10:19:50 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 11 Mar 2022 10:19:50 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v10]
In-Reply-To: <nk2sk9xm2MhASMPhc1RIgBmZdEq0bH8vQhij5bvntZI=.d5bad08a-55ce-48ac-86e9-c73417f5cdf3@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>
 <nk2sk9xm2MhASMPhc1RIgBmZdEq0bH8vQhij5bvntZI=.d5bad08a-55ce-48ac-86e9-c73417f5cdf3@github.com>
Message-ID: <xiWxAahF9HSWXdvN8jtB3JatJN3gGnrNU5upXp3v87A=.d4766296-2db6-4a5b-99bb-92b2c89e23cb@github.com>

On Fri, 11 Mar 2022 04:28:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey 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 'master' into 8282625
>>  - Correct indentation
>>  - Add unit test for DecimalFormatSymbols.getLocale()
>>  - Add comment about DecimalFormatSymbols being mutable objects.
>>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>>    
>>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>>    
>>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>>  - Revert "Correct caching test"
>>    
>>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
>>  - Correct caching test
>>  - Drop DecimalFormatSymbols.getLocale change
>>  - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation.
>>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/9cda7890...84fa1fe7
>
> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192:
> 
>> 190: 
>> 191:     /**
>> 192:      * {@return locale used to create this instance}
> 
> Hello Jim, the opening and closing `{`, I think aren't needed for a `@return`

This is actually a feature of JavaDoc. Accessor methods that require little description (self evident) can use {@return ...} to define the description and return in one go.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jpai at openjdk.java.net  Fri Mar 11 10:34:51 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 10:34:51 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v10]
In-Reply-To: <xiWxAahF9HSWXdvN8jtB3JatJN3gGnrNU5upXp3v87A=.d4766296-2db6-4a5b-99bb-92b2c89e23cb@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>
 <nk2sk9xm2MhASMPhc1RIgBmZdEq0bH8vQhij5bvntZI=.d5bad08a-55ce-48ac-86e9-c73417f5cdf3@github.com>
 <xiWxAahF9HSWXdvN8jtB3JatJN3gGnrNU5upXp3v87A=.d4766296-2db6-4a5b-99bb-92b2c89e23cb@github.com>
Message-ID: <IWkJE6_b2rAwCKG7J5OvyGAfCsMYdq25z2pmPW2jFdQ=.413405cf-fb37-4454-9c09-b34b246df691@github.com>

On Fri, 11 Mar 2022 10:16:33 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192:
>> 
>>> 190: 
>>> 191:     /**
>>> 192:      * {@return locale used to create this instance}
>> 
>> Hello Jim, the opening and closing `{`, I think aren't needed for a `@return`
>
> This is actually a feature of JavaDoc. Accessor methods that require little description (self evident) can use {@return ...} to define the description and return in one go.

Didn't know that, thank you for clarifying.

The rest of the changes look good to me.

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From jpai at openjdk.java.net  Fri Mar 11 10:34:50 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 11 Mar 2022 10:34:50 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v10]
In-Reply-To: <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
 <gl5z3OCquArZ3T-T7_MrOmu_O4JyrW4bG__Ov74N_Xk=.da5e905d-131b-41db-9e09-071f73133b4d@github.com>
Message-ID: <Mt8SsNnsnubCVvLctnI_5xgrIENmyGn92wkpAZhc91w=.59e88b8b-1ae7-4e9b-96f7-e221b42dd864@github.com>

On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
>> 
>> 
>> @Benchmark 
>> public void bigDecimalDefaultLocale() { 
>>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalLocaleAlternate() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void bigDecimalThaiLocale() { 
>>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>> } 
>> 
>> @Benchmark 
>> public void integerDefaultLocale() { 
>>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerLocaleAlternate() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> @Benchmark 
>> public void integerThaiLocale() { 
>>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>> } 
>> 
>> 
>> Before: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
>> 
>> After: 
>> Benchmark Mode Cnt Score Error Units 
>> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
>> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
>> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
>> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
>> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
>> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s
>
> Jim Laskey 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 'master' into 8282625
>  - Correct indentation
>  - Add unit test for DecimalFormatSymbols.getLocale()
>  - Add comment about DecimalFormatSymbols being mutable objects.
>  - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
>    
>    This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
>  - Revert "Drop DecimalFormatSymbols.getLocale change"
>    
>    This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
>  - Revert "Correct caching test"
>    
>    This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
>  - Correct caching test
>  - Drop DecimalFormatSymbols.getLocale change
>  - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation.
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/76644795...84fa1fe7

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From weijun at openjdk.java.net  Fri Mar 11 15:32:52 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 11 Mar 2022 15:32:52 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <OJXsIql3eK0cuKV5iLH_tmXrzKQkov7dukuN5CU5FQ4=.fb66f4aa-ff5d-45b9-a6fb-7fcb9c29f5bc@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

The security related changes look fine, except for the year 2021.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Fri Mar 11 20:48:17 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 11 Mar 2022 20:48:17 GMT
Subject: <i18n dev> RFR: 8282929: Localized monetary symbols are not
 reflected in `toLocalizedPattern` return value
Message-ID: <asloxswsXC9r3fwqhGNPt3Okmk5xBWVefvBJTL7iGy4=.0764c871-7ea4-4cd7-9c95-c8d3405bc87d@github.com>

`DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type.

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

Commit messages:
 - 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value

Changes: https://git.openjdk.java.net/jdk/pull/7790/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7790&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282929
  Stats: 70 lines in 2 files changed: 65 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7790.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7790/head:pull/7790

PR: https://git.openjdk.java.net/jdk/pull/7790

From naoto at openjdk.java.net  Fri Mar 11 22:20:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 11 Mar 2022 22:20:38 GMT
Subject: <i18n dev> RFR: 8282929: Localized monetary symbols are not
 reflected in `toLocalizedPattern` return value [v2]
In-Reply-To: <asloxswsXC9r3fwqhGNPt3Okmk5xBWVefvBJTL7iGy4=.0764c871-7ea4-4cd7-9c95-c8d3405bc87d@github.com>
References: <asloxswsXC9r3fwqhGNPt3Okmk5xBWVefvBJTL7iGy4=.0764c871-7ea4-4cd7-9c95-c8d3405bc87d@github.com>
Message-ID: <OwN5UFsn76IiNQDgee9AZvpEhgxHglTZDOhv-ep27TE=.4949b174-2cf3-4a93-8035-77f13b1710ec@github.com>

> `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type.

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

  Refined the test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7790/files
  - new: https://git.openjdk.java.net/jdk/pull/7790/files/a6cbf914..5064e354

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7790&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7790&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7790.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7790/head:pull/7790

PR: https://git.openjdk.java.net/jdk/pull/7790

From joehw at openjdk.java.net  Sat Mar 12 00:34:41 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Sat, 12 Mar 2022 00:34:41 GMT
Subject: <i18n dev> RFR: 8282929: Localized monetary symbols are not
 reflected in `toLocalizedPattern` return value [v2]
In-Reply-To: <OwN5UFsn76IiNQDgee9AZvpEhgxHglTZDOhv-ep27TE=.4949b174-2cf3-4a93-8035-77f13b1710ec@github.com>
References: <asloxswsXC9r3fwqhGNPt3Okmk5xBWVefvBJTL7iGy4=.0764c871-7ea4-4cd7-9c95-c8d3405bc87d@github.com>
 <OwN5UFsn76IiNQDgee9AZvpEhgxHglTZDOhv-ep27TE=.4949b174-2cf3-4a93-8035-77f13b1710ec@github.com>
Message-ID: <6pHxbPIB0nklM6wUOhO68T1NXQX9gqxYHE9wCcsyaGE=.c40b0b1b-0adc-496a-982d-968fc25992f2@github.com>

On Fri, 11 Mar 2022 22:20:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined the test

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7790

From lancea at openjdk.java.net  Sat Mar 12 16:33:38 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 12 Mar 2022 16:33:38 GMT
Subject: <i18n dev> RFR: 8282929: Localized monetary symbols are not
 reflected in `toLocalizedPattern` return value [v2]
In-Reply-To: <OwN5UFsn76IiNQDgee9AZvpEhgxHglTZDOhv-ep27TE=.4949b174-2cf3-4a93-8035-77f13b1710ec@github.com>
References: <asloxswsXC9r3fwqhGNPt3Okmk5xBWVefvBJTL7iGy4=.0764c871-7ea4-4cd7-9c95-c8d3405bc87d@github.com>
 <OwN5UFsn76IiNQDgee9AZvpEhgxHglTZDOhv-ep27TE=.4949b174-2cf3-4a93-8035-77f13b1710ec@github.com>
Message-ID: <7FMcOb-d6KfQt7eJeto4taZEc9iGV1p0HwGKyNA7rJY=.5681f965-a15d-4b2b-8d35-4871b1074bc4@github.com>

On Fri, 11 Mar 2022 22:20:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type.
>
> 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).

test/jdk/java/text/Format/DecimalFormat/ToLocalizedPatternTest.java line 29:

> 27:  * @summary Verifies that toLocalizedPattern() method correctly returns
> 28:  *          monetary symbols in a currency formatter
> 29:  * @run testng ToLocalizedPatternTest

Maybe run in othervm mode?

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

PR: https://git.openjdk.java.net/jdk/pull/7790

From naoto at openjdk.java.net  Sat Mar 12 20:36:39 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 12 Mar 2022 20:36:39 GMT
Subject: <i18n dev> RFR: 8282929: Localized monetary symbols are not
 reflected in `toLocalizedPattern` return value [v2]
In-Reply-To: <7FMcOb-d6KfQt7eJeto4taZEc9iGV1p0HwGKyNA7rJY=.5681f965-a15d-4b2b-8d35-4871b1074bc4@github.com>
References: <asloxswsXC9r3fwqhGNPt3Okmk5xBWVefvBJTL7iGy4=.0764c871-7ea4-4cd7-9c95-c8d3405bc87d@github.com>
 <OwN5UFsn76IiNQDgee9AZvpEhgxHglTZDOhv-ep27TE=.4949b174-2cf3-4a93-8035-77f13b1710ec@github.com>
 <7FMcOb-d6KfQt7eJeto4taZEc9iGV1p0HwGKyNA7rJY=.5681f965-a15d-4b2b-8d35-4871b1074bc4@github.com>
Message-ID: <8WUHE2zGWxkbOmNfRBfb9V1Ml-mUKs4OXUG-P0W5FmU=.0468a475-73fe-411a-bc88-a57b5fbc8ecc@github.com>

On Sat, 12 Mar 2022 16:27:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refined the test
>
> test/jdk/java/text/Format/DecimalFormat/ToLocalizedPatternTest.java line 29:
> 
>> 27:  * @summary Verifies that toLocalizedPattern() method correctly returns
>> 28:  *          monetary symbols in a currency formatter
>> 29:  * @run testng ToLocalizedPatternTest
> 
> Maybe run in othervm mode?

Thanks, Lance. I believe it is OK to run it in samejvm mode, as it does not leave any side effects.

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

PR: https://git.openjdk.java.net/jdk/pull/7790

From naoto at openjdk.java.net  Mon Mar 14 16:31:53 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Mar 2022 16:31:53 GMT
Subject: <i18n dev> Integrated: 8282929: Localized monetary symbols are not
 reflected in `toLocalizedPattern` return value
In-Reply-To: <asloxswsXC9r3fwqhGNPt3Okmk5xBWVefvBJTL7iGy4=.0764c871-7ea4-4cd7-9c95-c8d3405bc87d@github.com>
References: <asloxswsXC9r3fwqhGNPt3Okmk5xBWVefvBJTL7iGy4=.0764c871-7ea4-4cd7-9c95-c8d3405bc87d@github.com>
Message-ID: <tP-iTaEN90jN2LvdHzCwvRHP7IaCZnSSY2Ax84ZIjNk=.1a3d2b4f-b183-4728-8a10-f873263e25b5@github.com>

On Fri, 11 Mar 2022 19:53:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type.

This pull request has now been integrated.

Changeset: c96085ea
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c96085eaab1f6b21e084b94fcc619d090f0afc97
Stats:     68 lines in 2 files changed: 63 ins; 0 del; 5 mod

8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value

Reviewed-by: joehw, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/7790

From achung at openjdk.java.net  Mon Mar 14 16:41:48 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 16:41:48 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
 <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com>
Message-ID: <aFQYlAxHrt1xgVqg6IzAILy_arxPtISUJjV4XTInMIc=.98676675-43ef-44ef-bc29-935fb586e100@github.com>

On Thu, 10 Mar 2022 18:56:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved CurrencyNames changes to jdk.localedata
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305:
> 
>> 303:         {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"},
>> 304:         {"thread group number description name", "{0,number,integer}. {1} {2}"},
>> 305:         {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"},
> 
> I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added.

The translation was started before the updates to this file. This update can be done in the next msg drop.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From kizune at openjdk.java.net  Mon Mar 14 17:41:55 2022
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 14 Mar 2022 17:41:55 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <b1VgeZJ5V3QZYhPsCR9CXpev_t7FqNEWL4qF_rit7HA=.5ddff932-03a9-4b10-a199-ddc9c7e93d99@github.com>
Message-ID: <czftHGbEDrHytjmuT25dBWmgpN3gaiEPLmzDFtod0pA=.0c2274f6-25af-43fa-817f-0e41ede1c530@github.com>

On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   moved CurrencyNames changes to jdk.localedata

Marked as reviewed by kizune (Reviewer).

Clientlibs related stuff looks correct.

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From achung at openjdk.java.net  Mon Mar 14 20:39:46 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 14 Mar 2022 20:39:46 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed repeated lines from ROOT bundle in CurrencyNames

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/4735722d..d5c9b884

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01-02

  Stats: 675 lines in 3 files changed: 0 ins; 675 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Mon Mar 14 21:58:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Mar 2022 21:58:45 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <EX20WV-YgdYDcf8bAQVowI8_bLWbhpIVbE6VcPJuoAQ=.1bb0d805-0b7c-4e02-8a95-5c7d86b31c70@github.com>
Message-ID: <AePZQwkLsjSCRROANYizCTzIfiMBaWBOgZaVcnJtm5k=.132459fa-34c1-487f-b2c0-ce1d9e9e5f60@github.com>

On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed repeated lines from ROOT bundle in CurrencyNames

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties line 1:

> 1: #

The change to this file (moving ct.properties to ct_ja.properties) does look suspicious. Looks like this is not a translation file, but some kind of a configuration for `javac`. If so, it should not be translated (and translation configuration in the closed repository should exclude this file)

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From zgu at openjdk.java.net  Tue Mar 15 14:01:45 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 15 Mar 2022 14:01:45 GMT
Subject: <i18n dev> RFR: 8282887: Potential memory leak in
 sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern()
 on Windows
In-Reply-To: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
References: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
Message-ID: <8FQ5EWRNt4AntXLp7E2jD4bQho0c1T73LUCBJgDPa8Q=.8e9dabc6-b560-4cac-bdec-7b8117c975c3@github.com>

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`.

Friendly ping. May I have a second review, please!

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

PR: https://git.openjdk.java.net/jdk/pull/7777

From alanb at openjdk.java.net  Tue Mar 15 14:20:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 15 Mar 2022 14:20:46 GMT
Subject: <i18n dev> RFR: 8282887: Potential memory leak in
 sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern()
 on Windows
In-Reply-To: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
References: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
Message-ID: <OslX21dtjfImXP1BP2wnnYDLiN_SkChKXnJk2JLdXog=.e9cbb11b-c042-4540-bbe9-65e3c589f8b5@github.com>

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7777

From zgu at openjdk.java.net  Tue Mar 15 14:20:47 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 15 Mar 2022 14:20:47 GMT
Subject: <i18n dev> Integrated: 8282887: Potential memory leak in
 sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern()
 on Windows
In-Reply-To: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
References: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
Message-ID: <ZUtEROTluIkHLn8qvn2JCGgsXkdhwtE55bSbHBiArpY=.86d8b9bb-0f3c-4955-934d-5838d1f6d64a@github.com>

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`.

This pull request has now been integrated.

Changeset: 2cddf3f5
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2cddf3f5391518ea40796e6c4759047d51b7b312
Stats:     8 lines in 1 file changed: 2 ins; 3 del; 3 mod

8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

Reviewed-by: naoto, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/7777

From zgu at openjdk.java.net  Tue Mar 15 14:20:47 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 15 Mar 2022 14:20:47 GMT
Subject: <i18n dev> RFR: 8282887: Potential memory leak in
 sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern()
 on Windows
In-Reply-To: <s8ACRwWINelpYUK26aJSbIRXOLnxAsbyp2cxf1gVhjo=.09e42276-db78-4442-85c6-48f5c7d18cc4@github.com>
References: <jsnWL_n-NcBH7RCiQrqdekJoe9-gYwb_1j9_YiHfBuQ=.8de3ece4-3b18-4565-bb53-852138b2f59a@github.com>
 <s8ACRwWINelpYUK26aJSbIRXOLnxAsbyp2cxf1gVhjo=.09e42276-db78-4442-85c6-48f5c7d18cc4@github.com>
Message-ID: <_yHv28ooiVthtupJFkhLsUWAKJZE-1CUJF3UgcJjqd0=.6c5de42e-b376-4003-bd60-cfbbf1e7b0bf@github.com>

On Thu, 10 Mar 2022 19:46:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`.
>
> LGTM.

Thanks, @naotoj @AlanBateman

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

PR: https://git.openjdk.java.net/jdk/pull/7777

From ihse at openjdk.java.net  Tue Mar 15 23:50:22 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Mar 2022 23:50:22 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v5]
In-Reply-To: <VOISxSWArxxc_b4jkanMxAHICUEnv3wmh7yub1so5yg=.f062b37b-e0ef-4362-be5f-f73f170f3438@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <VOISxSWArxxc_b4jkanMxAHICUEnv3wmh7yub1so5yg=.f062b37b-e0ef-4362-be5f-f73f170f3438@github.com>
Message-ID: <ePFQlPZKK1cep2aZwODf_fUMzH_h_PIkUpuE4X4YIYc=.e2e51be7-635a-423b-97d2-41eeaf9ad5e0@github.com>

On Mon, 18 Jan 2021 13:47:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move characterdata templates to share/classes/java/lang.

This PR was almost ready to merge, but unfortunately got closed about a year ago when I disappeared on medical leave. :-( I've been putting off coming back to to this, worried that the merge conflicts would be bad. But no! Git handled the merge fantastically well; the default merge mode even realized that new files in a directory which had been moved elsewhere should probably also be moved to the same place. I was pleasantly surprised how easy this was. 

Nevertheless, I have carefully studied the automatic merge for any signs or mistakes. I only found one: a single renamed file (blacklist -> blocked) that it failed to match.

So I believe this PR is back in the same integrateable state that it was when I left it.

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Tue Mar 15 23:50:20 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Mar 2022 23:50:20 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

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 12 commits:

 - Merge branch 'master' into shuffle-data-reborn
 - Fix merge
 - Merge tag 'jdk-19+13' into shuffle-data-reborn
   
   Added tag jdk-19+13 for changeset 5df2a057
 - Move characterdata templates to share/classes/java/lang.
 - Update comment refering to "make" dir
 - Move new symbols to jdk.compiler
 - Merge branch 'master' into shuffle-data
 - Move macosxicons from share to macosx
 - Move to share/data, and move jdwp.spec to java.se
 - Update references in test
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

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

Changes: https://git.openjdk.java.net/jdk/pull/1611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=05
  Stats: 85 lines in 1695 files changed: 4 ins; 1 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Tue Mar 15 23:59:55 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Mar 2022 23:59:55 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
Message-ID: <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> 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 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>    
>    Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

I have carefully reviewed all PR comments, and the changes I made in response to them. I believe I have resolved all requests from reviewers. What remained to do was to create an informational JEP about the new source structure, and file some follow-up issues.

I have now created and submitted a new informational JEP ("JDK Source Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this JEP, it felt increasingly silly to just copy and extend the part about src/$MODULE from JEP 201, so I extended it to cover a relevant overview of the entire JDK source base structure. I actually think this JEP has a good merit on its own, notwithstanding it being a reviewer requirement for this PR.

I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and https://bugs.openjdk.java.net/browse/JDK-8283198, respectively).

I have filed a follow up issue for continued efforts to clean up charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228.

There were two open questions:

 * should jdwp.spec belong to specs directory instead of data
 * should bin/idea.sh be changed to exclude data

but they sounded so exploratory that I decided not to open JBS issues for them.

@wangweij  @naotoj  @prrace  @erikj79 @jonathan-gibbons  You have all approved this PR at an older revision. Can you please reconfirm that your approval stands for the latest revision? (Sorry for the mass ping)

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From Alan.Bateman at oracle.com  Wed Mar 16 06:31:24 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Mar 2022 06:31:24 +0000
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>
Message-ID: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com>

Magnus,

This proposal does not address the previous concerns. As before, you are 
proposing to put the data files used to generate the classes for 
jdk.localedata and jdk.charsets into src/java.base and I don't think we 
should do that. I really think this PR needs to be withdraw n or closed 
until there is at least some agreement on placement. I know you want to 
get the files moved out of the make tree but there are many issues to 
work through before that can happen.

-Alan

On 15/03/2022 23:59, Magnus Ihse Bursie wrote:
> On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>
>>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.)
>>>
>>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.)
>>>
>>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>>>
>>> ### Modules reviewed
>>>
>>> - [x] java.base
>>> - [x] java.desktop
>>> - [x] jdk.compiler
>>> - [x] java.se
>> 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 12 commits:
>>
>>   - Merge branch 'master' into shuffle-data-reborn
>>   - Fix merge
>>   - Merge tag 'jdk-19+13' into shuffle-data-reborn
>>     
>>     Added tag jdk-19+13 for changeset 5df2a057
>>   - Move characterdata templates to share/classes/java/lang.
>>   - Update comment refering to "make" dir
>>   - Move new symbols to jdk.compiler
>>   - Merge branch 'master' into shuffle-data
>>   - Move macosxicons from share to macosx
>>   - Move to share/data, and move jdwp.spec to java.se
>>   - Update references in test
>>   - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f
> I have carefully reviewed all PR comments, and the changes I made in response to them. I believe I have resolved all requests from reviewers. What remained to do was to create an informational JEP about the new source structure, and file some follow-up issues.
>
> I have now created and submitted a new informational JEP ("JDK Source Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this JEP, it felt increasingly silly to just copy and extend the part about src/$MODULE from JEP 201, so I extended it to cover a relevant overview of the entire JDK source base structure. I actually think this JEP has a good merit on its own, notwithstanding it being a reviewer requirement for this PR.
>
> I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and https://bugs.openjdk.java.net/browse/JDK-8283198, respectively).
>
> I have filed a follow up issue for continued efforts to clean up charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228.
>
> There were two open questions:
>
>   * should jdwp.spec belong to specs directory instead of data
>   * should bin/idea.sh be changed to exclude data
>
> but they sounded so exploratory that I decided not to open JBS issues for them.
>
> @wangweij  @naotoj  @prrace  @erikj79 @jonathan-gibbons  You have all approved this PR at an older revision. Can you please reconfirm that your approval stands for the latest revision? (Sorry for the mass ping)
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1611


From magnus.ihse.bursie at oracle.com  Wed Mar 16 08:44:51 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Mar 2022 09:44:51 +0100
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>
 <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com>
Message-ID: <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com>

On 2022-03-16 07:31, Alan Bateman wrote:
> Magnus,
>
> This proposal does not address the previous concerns. As before, you 
> are proposing to put the data files used to generate the classes for 
> jdk.localedata and jdk.charsets into src/java.base and I don't think 
> we should do that. I really think this PR needs to be withdraw n or 
> closed until there is at least some agreement on placement. I know you 
> want to get the files moved out of the make tree but there are many 
> issues to work through before that can happen.

I'm sorry that you feel I did not properly address your concerns. You wrote:

"If you are moving them into the src tree then src/java.base (as you 
have it) is best but will still have the ugly wart that some of these 
mapping tables will be used to generate code for the jdk.charsets module."

which I interpreted as a need to file a follow-up issue to sort that 
out, not a veto on the entire PR.

If you have such strong opinions on the data files shared between 
java.base and jdk.charsets/jdk.localedata, I propose we leave them in 
make/data for the time being, clean up the associated mess, and then 
work out where they actually should be. Does that sound okay to you?

/Magnus
>
> -Alan
>
> On 15/03/2022 23:59, Magnus Ihse Bursie wrote:
>> On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie 
>> <ihse at openjdk.org> wrote:
>>
>>>> A lot (but not all) of the data in make/data is tied to a specific 
>>>> module. For instance, the publicsuffixlist is used by java.base, 
>>>> and fontconfig by java.desktop. (A few directories, like 
>>>> mainmanifest, is *actually* used by make for the whole build.)
>>>>
>>>> These data files should move to the module they belong to. The are, 
>>>> after all, "source code" for that module that is "compiler" into 
>>>> resulting deliverables, for that module. (But the "source code" 
>>>> language is not Java or C, but typically a highly domain specific 
>>>> language or data format, and the "compilation" is, often, a 
>>>> specialized transformation.)
>>>>
>>>> This misplacement of the data directory is most visible at code 
>>>> review time. When such data is changed, most of the time build-dev 
>>>> (or the new build label) is involved, even though this has nothing 
>>>> to do with the build. While this is annoying, a worse problem is if 
>>>> the actual team that needs to review the patch (i.e., the team 
>>>> owning the module) is missed in the review.
>>>>
>>>> ### Modules reviewed
>>>>
>>>> - [x] java.base
>>>> - [x] java.desktop
>>>> - [x] jdk.compiler
>>>> - [x] java.se
>>> 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 12 
>>> commits:
>>>
>>> ? - Merge branch 'master' into shuffle-data-reborn
>>> ? - Fix merge
>>> ? - Merge tag 'jdk-19+13' into shuffle-data-reborn
>>> ??? ??? Added tag jdk-19+13 for changeset 5df2a057
>>> ? - Move characterdata templates to share/classes/java/lang.
>>> ? - Update comment refering to "make" dir
>>> ? - Move new symbols to jdk.compiler
>>> ? - Merge branch 'master' into shuffle-data
>>> ? - Move macosxicons from share to macosx
>>> ? - Move to share/data, and move jdwp.spec to java.se
>>> ? - Update references in test
>>> ? - ... and 2 more: 
>>> https://git.openjdk.java.net/jdk/compare/83d77186...598f740f
>> I have carefully reviewed all PR comments, and the changes I made in 
>> response to them. I believe I have resolved all requests from 
>> reviewers. What remained to do was to create an informational JEP 
>> about the new source structure, and file some follow-up issues.
>>
>> I have now created and submitted a new informational JEP ("JDK Source 
>> Structure"), available at 
>> https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this 
>> JEP, it felt increasingly silly to just copy and extend the part 
>> about src/$MODULE from JEP 201, so I extended it to cover a relevant 
>> overview of the entire JDK source base structure. I actually think 
>> this JEP has a good merit on its own, notwithstanding it being a 
>> reviewer requirement for this PR.
>>
>> I have also filed follow up issues for the non-standard 
>> jdk.hotspot.agent `doc` and `test` directories 
>> (https://bugs.openjdk.java.net/browse/JDK-8283197 and 
>> https://bugs.openjdk.java.net/browse/JDK-8283198, respectively).
>>
>> I have filed a follow up issue for continued efforts to clean up 
>> charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228.
>>
>> There were two open questions:
>>
>> ? * should jdwp.spec belong to specs directory instead of data
>> ? * should bin/idea.sh be changed to exclude data
>>
>> but they sounded so exploratory that I decided not to open JBS issues 
>> for them.
>>
>> @wangweij? @naotoj? @prrace? @erikj79 @jonathan-gibbons? You have all 
>> approved this PR at an older revision. Can you please reconfirm that 
>> your approval stands for the latest revision? (Sorry for the mass ping)
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1611
>


From prr at openjdk.java.net  Wed Mar 16 17:19:57 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 16 Mar 2022 17:19:57 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
Message-ID: <_XwD8h3_L03wqvO0Na4_OoHwtdYInzjTKsOaFvqKfUY=.47ccb949-e5fe-49bb-b4b8-3bc36676910a@github.com>

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> 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 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>    
>    Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

How are folks reviewing this huge PR ?
My browser paints a few files and that's it, and the drop down list to "jump to" is too big to display - it says !

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From achung at openjdk.java.net  Wed Mar 16 18:31:55 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 16 Mar 2022 18:31:55 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>

> msg drop for jdk19, Mar 9, 2022

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  removed incorrect translation of compiler configuration file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7765/files
  - new: https://git.openjdk.java.net/jdk/pull/7765/files/d5c9b884..715a6ad7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02-03

  Stats: 2310 lines in 3 files changed: 0 ins; 2310 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765

PR: https://git.openjdk.java.net/jdk/pull/7765

From ihse at openjdk.java.net  Wed Mar 16 19:10:03 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Mar 2022 19:10:03 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
Message-ID: <l5MgAeu_4rZhm136NUZKKS0NdFXVMHC5GTel88Zq9nw=.4ca070cf-7a6c-4933-9ea0-a665344d1555@github.com>

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> 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 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>    
>    Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

It might be helpful to go to the webrev instead: https://openjdk.github.io/cr/?repo=jdk&pr=1611&range=05

Only the first dozen or so of files has actual changes; the rest are moved files.

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From Alan.Bateman at oracle.com  Wed Mar 16 19:53:11 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Mar 2022 19:53:11 +0000
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <qZZeW4Wwn9Rj_m5O9Cc6BKPn5k-6UHcuS1_1vd4ojPY=.b53ec8c1-cb6e-4b6c-ae9e-276ffcd9fd29@github.com>
 <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com>
 <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com>
Message-ID: <1ffca295-1c99-300e-1ac5-f81c51d8ef9b@oracle.com>

On 16/03/2022 08:44, Magnus Ihse Bursie wrote:
> :
>
> If you have such strong opinions on the data files shared between 
> java.base and jdk.charsets/jdk.localedata, I propose we leave them in 
> make/data for the time being, clean up the associated mess, and then 
> work out where they actually should be. Does that sound okay to you?

The concern, as before, is that it puts data files into src/java.base 
that are used by the build to generate classes/resources for the service 
provider modules.? We also have the complication that the charsets to 
include in java.base varies by platform so the module/package for each 
charset is decided at build time. It's always been low-priority to 
re-visit that and not clear if we could even get to an agreement easily 
because there are IBM platforms that want EBCDIC and other double byte 
charsets whereas other platforms don't want these in java.base. So yes, 
if you can drop the move of the charset data and CLDR data from the 
patch then it will make it easier to discuss.

You asked about the JDWP spec. This is the protocol spec that is used to 
generate the spec in HTML, and source files for the debugger front-end 
and backend (jdk.jdi and jdk.jdwp.agent modules). The "specs" directory 
might be right. There is another source file (jdwp-spec.md) that isn't 
in the src tree right now and they probably go together.

-Alan

From naoto at openjdk.java.net  Wed Mar 16 21:39:02 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 21:39:02 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
Message-ID: <uL1qYQhyw-HnhirdQVoQeH4tE13bCIN7DEObzGuCTRw=.5f300302-924b-447f-b075-a07602525e2e@github.com>

On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> 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 12 commits:
> 
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>    
>    Added tag jdk-19+13 for changeset 5df2a057
>  - Move characterdata templates to share/classes/java/lang.
>  - Update comment refering to "make" dir
>  - Move new symbols to jdk.compiler
>  - Merge branch 'master' into shuffle-data
>  - Move macosxicons from share to macosx
>  - Move to share/data, and move jdwp.spec to java.se
>  - Update references in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f

Looks good, with minor comments. Also I am assuming you will modify the copyright year for these files before the merge.

make/modules/jdk.charsets/Gensrc.gmk line 32:

> 30: # Generate files using the charsetmapping tool
> 31: #
> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping

Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611

From naoto at openjdk.java.net  Wed Mar 16 21:40:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 21:40:44 GMT
Subject: <i18n dev> RFR: 8280400: JDK 19 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
 <SJQ29Ut1Mvo1_wXVRH6czoCYrkVhBoLSsVr0-wC9H34=.78a2083f-774e-4f4a-97f7-b998a2042c49@github.com>
Message-ID: <e38JXXFphxIsB3GPU8tMLtEBR2d6nJ52y-1yWWYbA1I=.66a0c141-db54-4f02-8e75-28d9e562c002@github.com>

On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> msg drop for jdk19, Mar 9, 2022
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed incorrect translation of compiler configuration file

LGTM. Thanks for the change.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7765

From ihse at openjdk.java.net  Wed Mar 16 22:00:02 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Mar 2022 22:00:02 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <uL1qYQhyw-HnhirdQVoQeH4tE13bCIN7DEObzGuCTRw=.5f300302-924b-447f-b075-a07602525e2e@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <uL1qYQhyw-HnhirdQVoQeH4tE13bCIN7DEObzGuCTRw=.5f300302-924b-447f-b075-a07602525e2e@github.com>
Message-ID: <xPfvUF9d9MHdd1LV96sZzDSVwFPc38iwJnyzwtOB6e8=.b32d2a07-98ef-4471-8cec-780219f0eaa1@github.com>

On Wed, 16 Mar 2022 21:31:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> 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 12 commits:
>> 
>>  - Merge branch 'master' into shuffle-data-reborn
>>  - Fix merge
>>  - Merge tag 'jdk-19+13' into shuffle-data-reborn
>>    
>>    Added tag jdk-19+13 for changeset 5df2a057
>>  - Move characterdata templates to share/classes/java/lang.
>>  - Update comment refering to "make" dir
>>  - Move new symbols to jdk.compiler
>>  - Merge branch 'master' into shuffle-data
>>  - Move macosxicons from share to macosx
>>  - Move to share/data, and move jdwp.spec to java.se
>>  - Update references in test
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f
>
> make/modules/jdk.charsets/Gensrc.gmk line 32:
> 
>> 30: # Generate files using the charsetmapping tool
>> 31: #
>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping
> 
> Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too

This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. 

So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect.

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From naoto at openjdk.java.net  Wed Mar 16 22:04:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Mar 2022 22:04:49 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v6]
In-Reply-To: <xPfvUF9d9MHdd1LV96sZzDSVwFPc38iwJnyzwtOB6e8=.b32d2a07-98ef-4471-8cec-780219f0eaa1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <xl8_hHf-HbuyjrWguj8ClAyCOZUy3IKwlLuUlvxOWFo=.f3fa5577-1700-41d9-b54b-462c7b1e6b05@github.com>
 <uL1qYQhyw-HnhirdQVoQeH4tE13bCIN7DEObzGuCTRw=.5f300302-924b-447f-b075-a07602525e2e@github.com>
 <xPfvUF9d9MHdd1LV96sZzDSVwFPc38iwJnyzwtOB6e8=.b32d2a07-98ef-4471-8cec-780219f0eaa1@github.com>
Message-ID: <r3Yu_TxywowIeqCXQloQP2bcfc0rJK0cqi9rrrRMEzA=.90371299-a157-4cff-8b98-59ed4c9df1cf@github.com>

On Wed, 16 Mar 2022 21:56:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/jdk.charsets/Gensrc.gmk line 32:
>> 
>>> 30: # Generate files using the charsetmapping tool
>>> 31: #
>>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping
>> 
>> Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too
>
> This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. 
> 
> So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect.

Thanks for reminding me. Then yes, I'd agree with Alan. It'd be much simpler to exclude this from this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Wed Mar 16 23:53:19 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Mar 2022 23:53:19 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v7]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <XxglJ5kwv5B_DSVjOYKoP_Ero8RuKTf6aSeH4ddyL4w=.19d3461a-df6d-4fe2-b3af-37cd3634510e@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/598f740f..1c91b951

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=05-06

  Stats: 35 lines in 35 files changed: 0 ins; 0 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Thu Mar 17 00:07:53 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Mar 2022 00:07:53 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v8]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <Pp09fmlRR4_79FfeYtzUqD8TTap-zHGwfDmE_9B6UA4=.103348e9-b253-4b85-bb18-0c7315da59de@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore charsetmapping and cldr to make/data

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/1c91b951..34bb3c16

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=06-07

  Stats: 5 lines in 1079 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Thu Mar 17 00:12:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Mar 2022 00:12:38 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/34bb3c16..b1d1e4d8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From weijun at openjdk.java.net  Thu Mar 17 00:31:11 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 17 Mar 2022 00:31:11 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <Qt1pz_nCJp8pAtbqP7EhgIGA52lOCSX8Si36QLEFnSo=.4f2ad0f6-50aa-49ec-8ebb-7aab0afc0c64@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

The security-related change looks fine to me

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Thu Mar 17 00:31:13 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Mar 2022 00:31:13 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v2]
In-Reply-To: <qWfRMXCZQRc38lL3CnICumC8ASqtFw-D52PmWzNXQ_M=.f618debd-e14b-4182-b5b4-be2f01b90817@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
 <qWfRMXCZQRc38lL3CnICumC8ASqtFw-D52PmWzNXQ_M=.f618debd-e14b-4182-b5b4-be2f01b90817@github.com>
Message-ID: <QEFkbJ80L7Ak_7d7OzzarSIXPKLRQ9B6IYFtGKDumH4=.0d511e63-97cb-451c-b359-ff981aa7df78@github.com>

On Wed, 16 Dec 2020 18:34:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
>>> 
>>> I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:
>>> 
>>> > As to charsetmapping and cldrconverter, I believe they can reside in
>>> > java.base, as jdk.charsets and jdk.localedata modules depend on it.
>>> 
>>> Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart.
>>> 
>>> Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place.
>> 
>> I still stand by what I wrote above. It's best to put data in java.base for charsets/localedata. Otherwise we would have to duplicate some in each modules source directory.
>
>>I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is.
> 
> Although I am the current RE for the charsets component, I succeeded it from Alan/Sherman, so I would like to hear Alan's opinion on this.

@naotoj  @AlanBateman I have now rolled back any changes to make/data/cldr and make/data/charsetmapping.

I have also updated copyright years; thanks for reminding me Naoto!

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From erikj at openjdk.java.net  Thu Mar 17 13:35:35 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 17 Mar 2022 13:35:35 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <ZcrNp87tQwFuc1MKr8cIzCraEmoZ9TT_0L6R-oPo7To=.75b70b2c-b81a-456c-8145-f7d94e79ff58@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From naoto at openjdk.java.net  Thu Mar 17 16:15:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 17 Mar 2022 16:15:30 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <FXVfMSGbgAEEf__IzJBLOZFEefOlQbbwE0kMFWOPRbY=.db9b221e-e1b2-4b0f-a74f-b44e576f748a@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

LGTM. Thanks for the change, Magnus!

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611

From naoto at openjdk.java.net  Thu Mar 17 18:36:56 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 17 Mar 2022 18:36:56 GMT
Subject: <i18n dev> RFR: 8283277: ISO 4217 Amendment 171 Update
Message-ID: <g4UpfUtj8iahQ3GytfEK2x9GfPineQfSWvMS8cCS5xM=.b248898c-cd89-4b9d-9df9-36e81b1e2ad1@github.com>

This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1.

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

Commit messages:
 - 8283277: ISO 4217 Amendment 171 Update

Changes: https://git.openjdk.java.net/jdk/pull/7857/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7857&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283277
  Stats: 17 lines in 6 files changed: 3 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7857.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7857/head:pull/7857

PR: https://git.openjdk.java.net/jdk/pull/7857

From iris at openjdk.java.net  Thu Mar 17 21:26:32 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 17 Mar 2022 21:26:32 GMT
Subject: <i18n dev> RFR: 8283277: ISO 4217 Amendment 171 Update
In-Reply-To: <g4UpfUtj8iahQ3GytfEK2x9GfPineQfSWvMS8cCS5xM=.b248898c-cd89-4b9d-9df9-36e81b1e2ad1@github.com>
References: <g4UpfUtj8iahQ3GytfEK2x9GfPineQfSWvMS8cCS5xM=.b248898c-cd89-4b9d-9df9-36e81b1e2ad1@github.com>
Message-ID: <OgFSD0WcQDa0ARiC0SI4uqYmMxhHjDg9JWxz27ihIEc=.53582f91-9c09-45f2-a25a-e407bbd3868c@github.com>

On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7857

From joehw at openjdk.java.net  Thu Mar 17 22:27:34 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 17 Mar 2022 22:27:34 GMT
Subject: <i18n dev> RFR: 8283277: ISO 4217 Amendment 171 Update
In-Reply-To: <g4UpfUtj8iahQ3GytfEK2x9GfPineQfSWvMS8cCS5xM=.b248898c-cd89-4b9d-9df9-36e81b1e2ad1@github.com>
References: <g4UpfUtj8iahQ3GytfEK2x9GfPineQfSWvMS8cCS5xM=.b248898c-cd89-4b9d-9df9-36e81b1e2ad1@github.com>
Message-ID: <rnkls7BNQQuecIwvsZOrz4fllGQBrPWdAwR8RjqXHE4=.a166d0b6-d5f8-46af-a934-3c692da23d50@github.com>

On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7857

From alanb at openjdk.java.net  Fri Mar 18 10:03:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 18 Mar 2022 10:03:39 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <iaSVWMoy7XUxSHuU16EAsolpikohce17N2tOYMrI278=.5c8253db-c812-47c0-8d0b-b9ebc419175f@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Thanks for dropping the charset and locale data from the proposal. The updated proposal (b1d1e4d8) looks okay but I can't tell if you are planning to integrate this or wait until there is discussion on the locations proposed in the Informational JEP that you've just submitted. Maybe you plan to just integrate and then adjust/move again if needed? I suspect that JEP will need to includes a "specs" directory. It's okay to jdwp.spec into the java.se "data" directory for now I think "specs" would be a bette place for it.

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From magnus.ihse.bursie at oracle.com  Fri Mar 18 14:13:58 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Mar 2022 14:13:58 +0000
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <iaSVWMoy7XUxSHuU16EAsolpikohce17N2tOYMrI278=.5c8253db-c812-47c0-8d0b-b9ebc419175f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
 <iaSVWMoy7XUxSHuU16EAsolpikohce17N2tOYMrI278=.5c8253db-c812-47c0-8d0b-b9ebc419175f@github.com>
Message-ID: <62193BC0-B3FC-43E9-A65D-387708D85B3D@oracle.com>


> 18 mars 2022 kl. 11:04 skrev Alan Bateman <alanb at openjdk.java.net>:
> 
> I can't tell if you are planning to integrate this or wait until there is discussion on the locations proposed in the Informational JEP that you've just submitted. Maybe you plan to just integrate and then adjust/move again if needed?

I am *not* planning to wait for the JEP. (My perhaps cynical prediction is that it will be treated as a low-priority, bike-shedding playground which is unlikely to progress to its final stage for a year or so?)

The point of the informational JEP is that it is a living document. If the code changes, we can update the JEP. The JEP as it stands right now describes the code base as it will look when this PR is integrated. 

And yes, I?m open for more updates/changes in the future if we find the need. Things like code structure is something which we impose on the source code to be helpful. If it works against our best interests, we need to change it. And sometimes it?s hard to get things right the first time around. 

/Magnus


From alanb at openjdk.java.net  Fri Mar 18 19:37:34 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 18 Mar 2022 19:37:34 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <TThDYnpnGRT5MhJzfyt921c0w1PSkGTzCKyX4x5YgDo=.0da11dd1-a5f9-4c52-ac2c-b695d73e48c2@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From prr at openjdk.java.net  Fri Mar 18 21:21:30 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Mar 2022 21:21:30 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <dzAkXMPIILgKRPK-x9XJVaFW2d_NA03CGuMkvlc0DVg=.39d1e835-937b-4c06-8208-889ba1f7ba26@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Changes requested by prr (Reviewer).

make/modules/java.desktop/gensrc/GensrcX11Wrappers.gmk line 27:

> 25: 
> 26: # Generate java sources using the X11 offsets that are precalculated in files
> 27: # src/java.desktop/share/data/x11wrappergen/sizes-<address size>.txt.

This doesn't seem right to me. This is X11 specific. It should not be in share.
Same for related files.

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From prr at openjdk.java.net  Fri Mar 18 21:27:36 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 18 Mar 2022 21:27:36 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
Message-ID: <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>

On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

This doesn't seem right to me to put x11wrappergen into share.

This is X11 specific. It should not be in share.

Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories.

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Mon Mar 21 13:41:40 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 13:41:40 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v10]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <On8dlZu4vW14u7WoEcc7K-dxlfaR_LNubtfe1UylTX4=.0b49d0c3-978f-4ae0-8376-860a9e24ad1d@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix fontconfig according to review request

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/b1d1e4d8..5a75e7d1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=08-09

  Stats: 26 lines in 5 files changed: 10 ins; 5 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Mon Mar 21 13:46:27 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 13:46:27 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v11]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <Y7NUBj6Z_EjhTNfXABIhR-XtHoCimtCttXC-H9fN_vQ=.856678a9-ef4d-417b-9d65-fe21b0629e68@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

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 18 commits:

 - Merge tag 'jdk-19+14' into shuffle-data
   
   Added tag jdk-19+14 for changeset 08cadb47
 - Move x11wrappergen from share/data to unix/data
 - Fix fontconfig according to review request
 - Fix typos
 - Restore charsetmapping and cldr to make/data
 - Update copyright year
 - Merge branch 'master' into shuffle-data-reborn
 - Fix merge
 - Merge tag 'jdk-19+13' into shuffle-data-reborn
   
   Added tag jdk-19+13 for changeset 5df2a057
 - Move characterdata templates to share/classes/java/lang.
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/08cadb47...ea17b206

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

Changes: https://git.openjdk.java.net/jdk/pull/1611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=10
  Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Mon Mar 21 14:15:36 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 14:15:36 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
 <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>
Message-ID: <sTEilApbgCtDnzUN4M2UE2Uuie52Bp4KflqHS4lTL_s=.430bd2c4-76a5-47c0-aa07-7cbf26c6a4e0@github.com>

On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
> 
> This is X11 specific. It should not be in share.
> 
> Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories.

@prrace I have now moved the fontconfig files to `$OS/data`. (I also took the opportunity to clean up the GenData file, which had a quite hairy logic for a trivial task.) I have moved the x11wrappergen files to `unix/data`. 

(Strictly speaking, "unix" and "x11" do not have the same "sense" (in the Fregean meaning), even if it has the same "referent". But we've used that convention before so I'm sticking to it.)

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From naoto at openjdk.java.net  Mon Mar 21 15:36:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 21 Mar 2022 15:36:41 GMT
Subject: <i18n dev> Integrated: 8283277: ISO 4217 Amendment 171 Update
In-Reply-To: <g4UpfUtj8iahQ3GytfEK2x9GfPineQfSWvMS8cCS5xM=.b248898c-cd89-4b9d-9df9-36e81b1e2ad1@github.com>
References: <g4UpfUtj8iahQ3GytfEK2x9GfPineQfSWvMS8cCS5xM=.b248898c-cd89-4b9d-9df9-36e81b1e2ad1@github.com>
Message-ID: <lgHu7PJyVaIBY-rgP_L8noZ6iLPM8Bi0DBOY1pNcJCY=.5adcd0a7-cf4e-4890-af83-fe9359d48b2b@github.com>

On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1.

This pull request has now been integrated.

Changeset: c4dc58e1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c4dc58e12e197562dce90c0027aa74c29047cea6
Stats:     17 lines in 6 files changed: 3 ins; 0 del; 14 mod

8283277: ISO 4217 Amendment 171 Update

Reviewed-by: iris, joehw

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

PR: https://git.openjdk.java.net/jdk/pull/7857

From ihse at openjdk.java.net  Mon Mar 21 16:06:35 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 16:06:35 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v12]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <F5oPHTPSHGam_cd_srYyubqcjvB_0j3m4q3sxfawsAg=.7f5555b0-7b16-4dc9-857f-62a2a401da7a@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Correct name for bfc files

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/ea17b206..f66afd1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=10-11

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Mon Mar 21 16:29:25 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 16:29:25 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v13]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

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 20 commits:

 - Merge branch 'master' into shuffle-data
 - Correct name for bfc files
 - Merge tag 'jdk-19+14' into shuffle-data
   
   Added tag jdk-19+14 for changeset 08cadb47
 - Move x11wrappergen from share/data to unix/data
 - Fix fontconfig according to review request
 - Fix typos
 - Restore charsetmapping and cldr to make/data
 - Update copyright year
 - Merge branch 'master' into shuffle-data-reborn
 - Fix merge
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

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

Changes: https://git.openjdk.java.net/jdk/pull/1611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=12
  Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611

From erikj at openjdk.java.net  Mon Mar 21 17:07:40 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 21 Mar 2022 17:07:40 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v13]
In-Reply-To: <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
Message-ID: <opdfm7Z0vWIQswV0Xb72GPj_qdNYKj5or6H8p6XaPaA=.19a39cd9-ff67-4a53-b086-2d1e2d261003@github.com>

On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> 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 20 commits:
> 
>  - Merge branch 'master' into shuffle-data
>  - Correct name for bfc files
>  - Merge tag 'jdk-19+14' into shuffle-data
>    
>    Added tag jdk-19+14 for changeset 08cadb47
>  - Move x11wrappergen from share/data to unix/data
>  - Fix fontconfig according to review request
>  - Fix typos
>  - Restore charsetmapping and cldr to make/data
>  - Update copyright year
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

OS specific X11 and fontconfig looks good.

make/modules/java.desktop/gendata/GendataFontConfig.gmk line 57:

> 55:   TARGETS += $(FONTCONFIG_OUT_BIN_FILE)
> 56: 
> 57: endif

It says no newline at end of file, maybe add that if it's true.

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611

From prr at openjdk.java.net  Mon Mar 21 17:57:38 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 21 Mar 2022 17:57:38 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v9]
In-Reply-To: <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <KkQPXaD5NmHSqJIYI2j_kg2eKiomElctLf7iHhJYTa8=.72f8d446-7fa4-4e5a-975a-8021611c7cc1@github.com>
 <ZqanUtqrGJAofH28Ht5RObs0jRwwMWF_xeZQiBGsu34=.17c94d0a-31bf-4368-8878-439f049d731c@github.com>
Message-ID: <ssoH764XKtZcaeKQQUsZrr6Ox1mMgq-WTGu3Ke5UW38=.1de7c1bc-a106-4528-886f-ad0cc33b717a@github.com>

On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
> 
> This is X11 specific. It should not be in share.
> 
> Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories.

> @prrace I have now moved the fontconfig files to `$OS/data`. (I also took the opportunity to clean up the GenData file, which had a quite hairy logic for a trivial task.) I have moved the x11wrappergen files to `unix/data`.
> 
> (Strictly speaking, "unix" and "x11" do not have the same "sense" (in the Fregean meaning), even if it has the same "referent". But we've used that convention before so I'm sticking to it.)

Indeed they do not but it is a better approximation than "shared".

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From jjg at openjdk.java.net  Mon Mar 21 19:00:36 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 21 Mar 2022 19:00:36 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v13]
In-Reply-To: <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
Message-ID: <dzwmzU5bxVLo3jjEzFdqL3irm8gwaabl6Vvjxx19cVA=.ecfee429-d175-449e-9e33-c3e29d4852ff@github.com>

On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> 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 20 commits:
> 
>  - Merge branch 'master' into shuffle-data
>  - Correct name for bfc files
>  - Merge tag 'jdk-19+14' into shuffle-data
>    
>    Added tag jdk-19+14 for changeset 08cadb47
>  - Move x11wrappergen from share/data to unix/data
>  - Fix fontconfig according to review request
>  - Fix typos
>  - Restore charsetmapping and cldr to make/data
>  - Update copyright year
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

As before, the changes for `jdk.compiler` and `idk.javadoc` look OK, and if there is general consensus on the overall proposed move, then I think that overall it is a good idea.

I did not review the `jdk.compiler` in low-level detail, but scanning the webrev index file, the changes seemed OK, and a pure move (no lines changed.)

It might have been better to have handled this on a per-module basis, rather than all-at-once, but whatever ...

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From mchung at openjdk.java.net  Mon Mar 21 19:42:33 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 21 Mar 2022 19:42:33 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v13]
In-Reply-To: <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <zgclPzWS5pSW1Sjeh0589MH3KXwez6WcnXILajQAQmA=.8e03cff3-3f44-45d5-908c-741a990d1517@github.com>
Message-ID: <80sBZo5_9EhVEBljhwN7YRFwROLhSnYgNPH1Qg2tMOk=.061730ba-b085-4109-b5c9-ddbf0397301f@github.com>

On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> 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 20 commits:
> 
>  - Merge branch 'master' into shuffle-data
>  - Correct name for bfc files
>  - Merge tag 'jdk-19+14' into shuffle-data
>    
>    Added tag jdk-19+14 for changeset 08cadb47
>  - Move x11wrappergen from share/data to unix/data
>  - Fix fontconfig according to review request
>  - Fix typos
>  - Restore charsetmapping and cldr to make/data
>  - Update copyright year
>  - Merge branch 'master' into shuffle-data-reborn
>  - Fix merge
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d

I reviewed java.base and java.se.  I agree that java.se is a better home for jdwp.spec.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Mon Mar 21 21:30:29 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 21:30:29 GMT
Subject: <i18n dev> RFR: 8257733: Move module-specific data from make to
 respective module [v14]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <bQvx336XdMQBPLqKmuEYlQSxpZfq4KdyGGQlgXS9Lh4=.4525e76b-b105-4935-aec4-72e75b6faf9e@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add missing newline at EOF

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/1c47d82d..8faeff36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=12-13

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From ihse at openjdk.java.net  Mon Mar 21 21:39:38 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Mar 2022 21:39:38 GMT
Subject: <i18n dev> Integrated: 8257733: Move module-specific data from make
 to respective module
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <vYbOrE22zzQ4_jNylB1fKhlWCWq6CqS1bBCYGTlDQP8=.f6c27d21-a538-40e8-9b85-7c538a888a72@github.com>

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

This pull request has now been integrated.

Changeset: f8878cb0
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f8878cb0cc436993ef1222bc13b00b923d91aad1
Stats:     140 lines in 619 files changed: 14 ins; 6 del; 120 mod

8257733: Move module-specific data from make to respective module

Reviewed-by: jjg, weijun, naoto, erikj, prr, alanb, mchung

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

PR: https://git.openjdk.java.net/jdk/pull/1611

From jlaskey at openjdk.java.net  Tue Mar 22 13:37:35 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 22 Mar 2022 13:37:35 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v11]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <LX_EocrF9yyD7L02mHcwBgEF2Gq5Xwzbwu_Q7iNiqtQ=.bb90bf08-0548-4c35-9c47-a06a39ced84f@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey 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 15 additional commits since the last revision:

 - Merge branch 'master' into 8282625
 - Merge branch 'master' into 8282625
 - Correct indentation
 - Add unit test for DecimalFormatSymbols.getLocale()
 - Add comment about DecimalFormatSymbols being mutable objects.
 - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
   
   This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
 - Revert "Drop DecimalFormatSymbols.getLocale change"
   
   This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
 - Revert "Correct caching test"
   
   This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
 - Correct caching test
 - Drop DecimalFormatSymbols.getLocale change
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/b8892a70...ffb39f97

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/84fa1fe7..ffb39f97

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=09-10

  Stats: 9802 lines in 494 files changed: 4773 ins; 2477 del; 2552 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Tue Mar 22 13:45:20 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 22 Mar 2022 13:45:20 GMT
Subject: <i18n dev> RFR: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly [v12]
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <lTA3kRkWZtcfkg6pVJgv5k2MeTbXmpJjp7_RuD4WlLY=.18ff9ab0-740f-47c0-982a-ebcec8ded863@github.com>

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

Jim Laskey 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 16 additional commits since the last revision:

 - Merge branch 'master' into 8282625
 - Merge branch 'master' into 8282625
 - Merge branch 'master' into 8282625
 - Correct indentation
 - Add unit test for DecimalFormatSymbols.getLocale()
 - Add comment about DecimalFormatSymbols being mutable objects.
 - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation."
   
   This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72.
 - Revert "Drop DecimalFormatSymbols.getLocale change"
   
   This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110.
 - Revert "Correct caching test"
   
   This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5.
 - Correct caching test
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/cfdf1030...38251f9e

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7703/files
  - new: https://git.openjdk.java.net/jdk/pull/7703/files/ffb39f97..38251f9e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=10-11

  Stats: 1783 lines in 672 files changed: 858 ins; 698 del; 227 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703

PR: https://git.openjdk.java.net/jdk/pull/7703

From jlaskey at openjdk.java.net  Tue Mar 22 15:35:40 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 22 Mar 2022 15:35:40 GMT
Subject: <i18n dev> Integrated: JDK-8282625 Formatter caches
 Locale/DecimalFormatSymbols poorly
In-Reply-To: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
References: <D14DmMGurFQyfyxdC3x9dwtfdOk59lrpmn2dVPtObBw=.34ec766d-78b4-4df8-a07b-f70e4881f5bf@github.com>
Message-ID: <8BfY8fb-MQiDbbVPFHDxmUfCNHiLepzUz1seKxOkIIk=.98715874-1490-44c5-9adf-bb280cf01ac7@github.com>

On Fri, 4 Mar 2022 17:54:20 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. 
> 
> 
> @Benchmark 
> public void bigDecimalDefaultLocale() { 
>     result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalLocaleAlternate() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
>     other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void bigDecimalThaiLocale() { 
>     result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); 
> } 
> 
> @Benchmark 
> public void integerDefaultLocale() { 
>     result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerLocaleAlternate() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
>     other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> @Benchmark 
> public void integerThaiLocale() { 
>     result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); 
> } 
> 
> 
> Before: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s 
> 
> After: 
> Benchmark Mode Cnt Score Error Units 
> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s 
> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s 
> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s 
> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s 
> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s 
> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s

This pull request has now been integrated.

Changeset: 557ff4b3
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/557ff4b3558f95723ebaff680b8524b0cb979559
Stats:     93 lines in 3 files changed: 51 ins; 35 del; 7 mod

8282625: Formatter caches Locale/DecimalFormatSymbols poorly

Reviewed-by: naoto, rriggs, jpai

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

PR: https://git.openjdk.java.net/jdk/pull/7703

From naoto at openjdk.java.net  Tue Mar 22 18:50:13 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 22 Mar 2022 18:50:13 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out
 of date
Message-ID: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>

Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.

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

Commit messages:
 - 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date

Changes: https://git.openjdk.java.net/jdk/pull/7909/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7909&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283465
  Stats: 125 lines in 3 files changed: 50 ins; 73 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7909.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7909/head:pull/7909

PR: https://git.openjdk.java.net/jdk/pull/7909

From bpb at openjdk.java.net  Tue Mar 22 18:56:33 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 22 Mar 2022 18:56:33 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date
In-Reply-To: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
Message-ID: <fu5LKYcytDkqbzyg90o2dnbYdHVk4sSHegOeSp-0J-c=.460d5bfe-e9a2-4ce0-992c-8c469df2e0e7@github.com>

On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7909

From iris at openjdk.java.net  Tue Mar 22 19:04:32 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 22 Mar 2022 19:04:32 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date
In-Reply-To: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
Message-ID: <nbfBCy5SetabFt0VRxz_uEw04w82V5MqJkKjRJeic7o=.ddd841c4-da4c-42d3-82dc-351c65d46f9d@github.com>

On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7909

From smarks at openjdk.java.net  Tue Mar 22 21:46:40 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 22 Mar 2022 21:46:40 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date
In-Reply-To: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
Message-ID: <MgrQCEgr1JxmboMUZ4jTUfRTxJ6w46U5LOv_LfsSPT0=.5f24987f-2907-4f96-abac-eff80ba60f9c@github.com>

On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.

Thanks for doing this! I was going to offer to do this myself but you beat me to it. Rewritten test looks great.

src/java.base/share/classes/java/lang/Character.java line 740:

> 738:     public static final class UnicodeBlock extends Subset {
> 739:         /**
> 740:          * 737 - the expected number of entities

Just a quibble about this comment... it's probably not worth repeating the actual value. But it probably is worth mentioning that the actual value should (or must) match the number of entries added to the map by constructors called from the static initializers in this class. Whenever aliases or new blocks are added, this number must be adjusted.

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

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7909

From naoto at openjdk.java.net  Tue Mar 22 22:02:22 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 22 Mar 2022 22:02:22 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date [v2]
In-Reply-To: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
Message-ID: <BSPhn3DPKN78FlaxPvqMrVfD_TXym6SOsY5Ub70Sank=.d36a38d1-afe2-4481-aab6-47b2b1459bce@github.com>

> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.

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

  Comment adjusted per review suggestion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7909/files
  - new: https://git.openjdk.java.net/jdk/pull/7909/files/7328e1e7..ec77e17d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7909&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7909&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/7909

From naoto at openjdk.java.net  Tue Mar 22 22:02:23 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 22 Mar 2022 22:02:23 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date [v2]
In-Reply-To: <MgrQCEgr1JxmboMUZ4jTUfRTxJ6w46U5LOv_LfsSPT0=.5f24987f-2907-4f96-abac-eff80ba60f9c@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
 <MgrQCEgr1JxmboMUZ4jTUfRTxJ6w46U5LOv_LfsSPT0=.5f24987f-2907-4f96-abac-eff80ba60f9c@github.com>
Message-ID: <iUoQvBKWHE_ln-XUJ4zrDRWYVhhuOleG8jwsrUkjK4Q=.61053ad6-33d6-41c1-b054-11cb387de11d@github.com>

On Tue, 22 Mar 2022 21:42:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comment adjusted per review suggestion
>
> src/java.base/share/classes/java/lang/Character.java line 740:
> 
>> 738:     public static final class UnicodeBlock extends Subset {
>> 739:         /**
>> 740:          * 737 - the expected number of entities
> 
> Just a quibble about this comment... it's probably not worth repeating the actual value. But it probably is worth mentioning that the actual value should (or must) match the number of entries added to the map by constructors called from the static initializers in this class. Whenever aliases or new blocks are added, this number must be adjusted.

Not a "quibble" at all.  In fact, I thought the same just after I submitted the PR that the number in the comment would be easily overlooked and got stale, which would defy this cleanup. Removed the actual number and put some explanation there.

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

PR: https://git.openjdk.java.net/jdk/pull/7909

From bpb at openjdk.java.net  Tue Mar 22 22:22:29 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 22 Mar 2022 22:22:29 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date [v2]
In-Reply-To: <BSPhn3DPKN78FlaxPvqMrVfD_TXym6SOsY5Ub70Sank=.d36a38d1-afe2-4481-aab6-47b2b1459bce@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
 <BSPhn3DPKN78FlaxPvqMrVfD_TXym6SOsY5Ub70Sank=.d36a38d1-afe2-4481-aab6-47b2b1459bce@github.com>
Message-ID: <_amdaFT3AdjVDaWdk2kCwJpIC7kU7iiy_hlF5HetF40=.080394fc-f51e-4808-afe6-c34bc0b40fb0@github.com>

On Tue, 22 Mar 2022 22:02:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment adjusted per review suggestion

Added comments look good.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7909

From iris at openjdk.java.net  Tue Mar 22 22:22:29 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 22 Mar 2022 22:22:29 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date [v2]
In-Reply-To: <BSPhn3DPKN78FlaxPvqMrVfD_TXym6SOsY5Ub70Sank=.d36a38d1-afe2-4481-aab6-47b2b1459bce@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
 <BSPhn3DPKN78FlaxPvqMrVfD_TXym6SOsY5Ub70Sank=.d36a38d1-afe2-4481-aab6-47b2b1459bce@github.com>
Message-ID: <jJCHjlPK0lnN_ZvArtaLKaxvXqs19f3VwiTZ_pQZb_8=.949fe322-a9c5-4462-8163-b3d149032daa@github.com>

On Tue, 22 Mar 2022 22:02:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment adjusted per review suggestion

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7909

From smarks at openjdk.java.net  Wed Mar 23 02:49:35 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 23 Mar 2022 02:49:35 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date [v2]
In-Reply-To: <BSPhn3DPKN78FlaxPvqMrVfD_TXym6SOsY5Ub70Sank=.d36a38d1-afe2-4481-aab6-47b2b1459bce@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
 <BSPhn3DPKN78FlaxPvqMrVfD_TXym6SOsY5Ub70Sank=.d36a38d1-afe2-4481-aab6-47b2b1459bce@github.com>
Message-ID: <e9TBICMn3PkmIO7PRbvOR6FPvDWnqcP0oRivlGhiirY=.f317d5b7-66c0-455a-9bdf-93b2a2e93d75@github.com>

On Tue, 22 Mar 2022 22:02:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment adjusted per review suggestion

Marked as reviewed by smarks (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7909

From smarks at openjdk.java.net  Wed Mar 23 02:49:36 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 23 Mar 2022 02:49:36 GMT
Subject: <i18n dev> RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is
 out of date [v2]
In-Reply-To: <iUoQvBKWHE_ln-XUJ4zrDRWYVhhuOleG8jwsrUkjK4Q=.61053ad6-33d6-41c1-b054-11cb387de11d@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
 <MgrQCEgr1JxmboMUZ4jTUfRTxJ6w46U5LOv_LfsSPT0=.5f24987f-2907-4f96-abac-eff80ba60f9c@github.com>
 <iUoQvBKWHE_ln-XUJ4zrDRWYVhhuOleG8jwsrUkjK4Q=.61053ad6-33d6-41c1-b054-11cb387de11d@github.com>
Message-ID: <0ltI4ZnuHK9ktozuhdEOZ2fGOdRQ_ORZ18V3MOeudpE=.b5ee7e6a-38e1-4104-9e4b-15155b77b1db@github.com>

On Tue, 22 Mar 2022 21:58:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 740:
>> 
>>> 738:     public static final class UnicodeBlock extends Subset {
>>> 739:         /**
>>> 740:          * 737 - the expected number of entities
>> 
>> Just a quibble about this comment... it's probably not worth repeating the actual value. But it probably is worth mentioning that the actual value should (or must) match the number of entries added to the map by constructors called from the static initializers in this class. Whenever aliases or new blocks are added, this number must be adjusted.
>
> Not a "quibble" at all.  In fact, I thought the same just after I submitted the PR that the number in the comment would be easily overlooked and got stale, which would defy this cleanup. Removed the actual number and put some explanation there.

Thanks, looks good.

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

PR: https://git.openjdk.java.net/jdk/pull/7909

From naoto at openjdk.java.net  Wed Mar 23 19:47:32 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 23 Mar 2022 19:47:32 GMT
Subject: <i18n dev> Integrated: 8283465: Character.UnicodeBlock.NUM_ENTITIES
 is out of date
In-Reply-To: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
References: <RC2CgofaoEW9NDfIJm92uGVUe_AI1FF7PrjOleCcSM4=.ef1554d2-87a9-47bb-949f-276f89dc0ec7@github.com>
Message-ID: <ZAHX3u7DtjJ8V6zu0tfD6tRF7uB8kpV-0SekjryZlmw=.a1d77617-f65f-44d3-ae27-61e795030bd0@github.com>

On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value.

This pull request has now been integrated.

Changeset: 0ee65e1f
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0ee65e1ff3eaed4a8a2542562f0ba2a61d0f5894
Stats:     128 lines in 3 files changed: 53 ins; 73 del; 2 mod

8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date

Reviewed-by: bpb, iris, smarks

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

PR: https://git.openjdk.java.net/jdk/pull/7909

From psadhukhan at openjdk.java.net  Thu Mar 24 06:50:07 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 24 Mar 2022 06:50:07 GMT
Subject: <i18n dev> RFR: 8283608: Refactor 2d,
 beans classes javadoc to use @throws instead of @exception
Message-ID: <cROy0eoUkBAdp5IOIcK9IcTzJtC7ZBDieR1ljOFnCmc=.9d1c8017-a0e2-4f16-85ea-42cd6f0a511c@github.com>

Prevailing JDK coding practices use "@throws" rather than "@exception".
Need to refactor remaining 2d, beans,sound classes to use @throws

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

Commit messages:
 - Fix
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7937/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7937&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283608
  Stats: 56 lines in 22 files changed: 0 ins; 1 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7937.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7937/head:pull/7937

PR: https://git.openjdk.java.net/jdk/pull/7937

From naoto at openjdk.java.net  Thu Mar 24 22:11:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 24 Mar 2022 22:11:30 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
Message-ID: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>

Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

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

Commit messages:
 - 8282819: Deprecate Locale class constructors

Changes: https://git.openjdk.java.net/jdk/pull/7947/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282819
  Stats: 904 lines in 196 files changed: 74 ins; 22 del; 808 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7947.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947

PR: https://git.openjdk.java.net/jdk/pull/7947

From smarks at openjdk.java.net  Fri Mar 25 00:25:47 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 25 Mar 2022 00:25:47 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

Specs looks good, with minor modifications. I'm not so sure about replacement of the constructors with string concatenation with ternary operators; see my other comment.

src/java.base/share/classes/java/util/Locale.java line 252:

> 250:  * <p>The {@code Locale} class provides a number of convenient constants
> 251:  * that you can use to obtain {@code Locale} objects for commonly used
> 252:  * locales. For example, the following obtains a {@code Locale} object

I'd replace this part (and the example below) with something like,

    For example, {@code Locale.US} is the {@code Locale} object for the United States.

src/java.base/share/classes/java/util/Locale.java line 2511:

> 2509:      * constructors, the {@code Builder} checks if a value configured by a
> 2510:      * setter satisfies the syntax requirements defined by the {@code Locale}
> 2511:      * class.  A {@code Locale} object obtained by a {@code Builder} is

...obtained from a Builder...

src/java.base/share/classes/java/util/Locale.java line 2526:

> 2524:      *
> 2525:      * <p>The following example shows how to obtain a {@code Locale} object
> 2526:      * with the {@code Builder}.

...shows how to obtain a Locale object using a Builder.

src/java.base/share/classes/java/util/Locale.java line 2660:

> 2658:          *
> 2659:          * <p>The country value in the {@code Locale} obtained by the
> 2660:          * {@code Builder} is always normalized to upper case.

...obtained from a Builder...

src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375:

> 373:                         (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) +
> 374:                         (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) +
> 375:                         (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant()));

It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide?

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Fri Mar 25 01:59:51 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 01:59:51 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>
Message-ID: <OBsFbX0ds7pjRk7RgpbdV4Zn8KOlnZlxty5xXmq8tPs=.55c6d83e-91d9-4c7d-9157-cab06c6f2f0a@github.com>

On Fri, 25 Mar 2022 00:18:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375:
> 
>> 373:                         (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) +
>> 374:                         (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) +
>> 375:                         (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant()));
> 
> It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide?

True. One solution could be to expose `Locale.getInstance()`, which is currently a package-private static method, for this purpose. Though that means promoting `ill-formed` locale objects which defy some part of the deprecation cause.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From rriggs at openjdk.java.net  Fri Mar 25 15:40:46 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Mar 2022 15:40:46 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

src/java.base/share/classes/java/util/Locale.java line 245:

> 243:  * <h4>Factory Method</h4>
> 244:  *
> 245:  * <p>The method {@link #forLanguageTag} obtains a {@code Locale}

The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory.
Yes, it already exists and does what's required but you might get better uptake with a more natural name.

Some alternatives:
 - `Locale.of("en_US")` - short and conventional
 - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
 - `Locale.forLanguage("en_US")` - natural but less conventional

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From rriggs at openjdk.java.net  Fri Mar 25 16:21:52 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 25 Mar 2022 16:21:52 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <rvpu-eVSZUdEqfnckoWr-J9r6wzDOxNjzSbyW5aFOjE=.8654bef5-9b34-4618-92f7-b9a1bf0c13fa@github.com>

On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

Given the large number of cleanups, I would have suggested to keep them separate from the change to re-focus the API on factories.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Fri Mar 25 16:21:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 16:21:52 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
In-Reply-To: <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <tyOR0vEQfJzdx8ZwYHY45srRuXftQXscF48fPmAXqRs=.fd7f148b-cef1-41d9-8f7c-59c8bfcda8e5@github.com>
Message-ID: <WWaUZ9i-O6PCG638nKOBsZabzM2ssK5gzG_SDVattvE=.d63a8f82-17f8-4ed2-bed6-ba717c04b545@github.com>

On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> src/java.base/share/classes/java/util/Locale.java line 245:
> 
>> 243:  * <h4>Factory Method</h4>
>> 244:  *
>> 245:  * <p>The method {@link #forLanguageTag} obtains a {@code Locale}
> 
> The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory.
> Yes, it already exists and does what's required but you might get better uptake with a more natural name.
> 
> Some alternatives:
>  - `Locale.of("en_US")` - short and conventional
>  - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories
>  - `Locale.forLanguage("en_US")` - natural but less conventional

I was thinking of a *new* factory method, along the line with Stuart's suggestion, something like this:

Locale.of(String... elements)

where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or `(lang, ctry, vrnt, scpt)`. Either element can be an empty string, but cannot be null. These elements are *not* language tags, but conventional arguments to constructors, so it is compatible (and works as a stop-gap) to the old constructors. This way third parties will not have to deal with the boilerplate code mentioned above on migration.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Fri Mar 25 21:53:27 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 21:53:27 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v2]
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <nflS_VICel73haRNgrocSXY3THUwu88DV7uRQg_I_y0=.5d8c5fd6-519b-4a13-a7c4-f4887499f71d@github.com>

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

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

  Added a new factory method, removed pure refactoring from Locale API changes.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7947/files
  - new: https://git.openjdk.java.net/jdk/pull/7947/files/9ff69cbe..e874ff7e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=00-01

  Stats: 887 lines in 193 files changed: 37 ins; 67 del; 783 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7947.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Fri Mar 25 22:14:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 22:14:48 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v2]
In-Reply-To: <OBsFbX0ds7pjRk7RgpbdV4Zn8KOlnZlxty5xXmq8tPs=.55c6d83e-91d9-4c7d-9157-cab06c6f2f0a@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <RSdSQRML_fxp83kPgyjhwRAbLU9aQ7gmcwt485ai5MU=.e2fcbdd7-d325-4ac2-ade5-2a2bfa1658ee@github.com>
 <OBsFbX0ds7pjRk7RgpbdV4Zn8KOlnZlxty5xXmq8tPs=.55c6d83e-91d9-4c7d-9157-cab06c6f2f0a@github.com>
Message-ID: <oFr3DVaGXxM_BxKdVyThGSWGSsxxjyU2bK8ePzIxexE=.fc799446-090f-4416-bb99-a967d1b8614d@github.com>

On Fri, 25 Mar 2022 01:56:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375:
>> 
>>> 373:                         (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) +
>>> 374:                         (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) +
>>> 375:                         (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant()));
>> 
>> It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide?
>
> True. One solution could be to expose `Locale.getInstance()`, which is currently a package-private static method, for this purpose. Though that means promoting `ill-formed` locale objects which defy some part of the deprecation cause.

Introduced a new `Locale.of(String...)` method.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Fri Mar 25 22:51:23 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 25 Mar 2022 22:51:23 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v3]
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

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

  Fixed a build failure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7947/files
  - new: https://git.openjdk.java.net/jdk/pull/7947/files/e874ff7e..b4d040af

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From lancea at openjdk.java.net  Sat Mar 26 11:33:44 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 26 Mar 2022 11:33:44 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v3]
In-Reply-To: <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>
Message-ID: <sayxiM8JrZR4IU2xc9vYjs57hv4aOgyCNSOicnqrh8U=.6765533c-ba13-424f-bad3-16b7a644f75c@github.com>

On Fri, 25 Mar 2022 22:51:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a build failure

Hi Naoto,

I think the changes look good.

One suggestion
As part of the PR, we should probably update test/jdk/java/util/Locale/LocaleTest.java. or perhaps add a new test for Locale.of() for completeness.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From duke at openjdk.java.net  Sun Mar 27 08:51:41 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Sun, 27 Mar 2022 08:51:41 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v3]
In-Reply-To: <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>
Message-ID: <IYnWChv0pLYc6MJpLkLhHwNvAtTKZcCiQoyy6LpfMQo=.d345951b-8a67-4b36-9727-e143f99af03e@github.com>

On Fri, 25 Mar 2022 22:51:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed a build failure

src/java.base/share/classes/java/util/Locale.java line 819:

> 817:      * @since 19
> 818:      */
> 819:     public static Locale of(String... fields) {

Arguably, there?should?be `Locale.of`?overloads taking?0 to?4?arguments, so?that it?s?not?necessary to?box the?fields in?a?`String`?array.

src/java.base/share/classes/java/util/Locale.java line 825:

> 823:             case 2 -> getInstance(fields[0], "", fields[1], "", null);
> 824:             case 3 -> getInstance(fields[0], "", fields[1], fields[2], null);
> 825:             default -> getInstance(fields[0], fields[3], fields[1], fields[2], null);

This?should probably?throw `IllegalArgumentException` when?more?than 4?fields are?passed:
Suggestion:

            case 4 -> getInstance(fields[0], fields[3], fields[1], fields[2], null);
            default -> throw new IllegalArgumentException(/* TODO: message */);

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From redestad at openjdk.java.net  Mon Mar 28 12:00:52 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 28 Mar 2022 12:00:52 GMT
Subject: <i18n dev> RFR: 8283781: Avoid allocating unused lastRulesCaches
Message-ID: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>

This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.

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

Commit messages:
 - Merge branch 'master' into lastRulesCache
 - Avoid allocating unused lastRulesCaches

Changes: https://git.openjdk.java.net/jdk/pull/7990/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7990&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283781
  Stats: 16 lines in 1 file changed: 9 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7990.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7990/head:pull/7990

PR: https://git.openjdk.java.net/jdk/pull/7990

From rriggs at openjdk.java.net  Mon Mar 28 14:20:49 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 28 Mar 2022 14:20:49 GMT
Subject: <i18n dev> RFR: 8283781: Avoid allocating unused lastRulesCaches
In-Reply-To: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>
References: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>
Message-ID: <rfsZKI8qVsYxxV5OI3mPIMVbmN5I6gcP2HwLnsYqhmU=.8e41c026-5a8c-4f23-8171-a94e2f7975e3@github.com>

On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7990

From naoto at openjdk.java.net  Mon Mar 28 16:02:51 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 16:02:51 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v3]
In-Reply-To: <sayxiM8JrZR4IU2xc9vYjs57hv4aOgyCNSOicnqrh8U=.6765533c-ba13-424f-bad3-16b7a644f75c@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>
 <sayxiM8JrZR4IU2xc9vYjs57hv4aOgyCNSOicnqrh8U=.6765533c-ba13-424f-bad3-16b7a644f75c@github.com>
Message-ID: <t4XMpQNies_67vu804V_nLlPqhWw5eZNqMqMXorxhbc=.4952c7eb-f3af-4c77-9059-31d24404256f@github.com>

On Sat, 26 Mar 2022 11:30:53 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> One suggestion As part of the PR, we should probably update test/jdk/java/util/Locale/LocaleTest.java. or perhaps add a new test for Locale.of() for completeness.

Thanks, Lance. Sure, I will add some new unit tests for the new method.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Mon Mar 28 16:02:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 16:02:52 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v3]
In-Reply-To: <IYnWChv0pLYc6MJpLkLhHwNvAtTKZcCiQoyy6LpfMQo=.d345951b-8a67-4b36-9727-e143f99af03e@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>
 <IYnWChv0pLYc6MJpLkLhHwNvAtTKZcCiQoyy6LpfMQo=.d345951b-8a67-4b36-9727-e143f99af03e@github.com>
Message-ID: <hMnD7rywZCJIk-qk3y_ILTZ7qu1ZnVCfuz308rYtxyI=.969e7735-40c1-40e3-a891-a87f6b55d586@github.com>

On Sun, 27 Mar 2022 08:45:01 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed a build failure
>
> src/java.base/share/classes/java/util/Locale.java line 819:
> 
>> 817:      * @since 19
>> 818:      */
>> 819:     public static Locale of(String... fields) {
> 
> Arguably, there?should?be `Locale.of`?overloads taking?0 to?4?arguments, so?that it?s?not?necessary to?box the?fields in?a?`String`?array.

While it is true for completeness, I would limit the addition of new method as little as possible, because there are already several ways to obtain a Locale object.

> src/java.base/share/classes/java/util/Locale.java line 825:
> 
>> 823:             case 2 -> getInstance(fields[0], "", fields[1], "", null);
>> 824:             case 3 -> getInstance(fields[0], "", fields[1], fields[2], null);
>> 825:             default -> getInstance(fields[0], fields[3], fields[1], fields[2], null);
> 
> This?should probably?throw `IllegalArgumentException` when?more?than 4?fields are?passed:
> Suggestion:
> 
>             case 4 -> getInstance(fields[0], fields[3], fields[1], fields[2], null);
>             default -> throw new IllegalArgumentException(/* TODO: message */);

Thanks for the suggestion. Will incorporate the exception in the spec/impl.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Mon Mar 28 16:19:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 16:19:49 GMT
Subject: <i18n dev> RFR: 8283781: Avoid allocating unused lastRulesCaches
In-Reply-To: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>
References: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>
Message-ID: <8LXzDrnkPyTwy3doogVJg6iE1i4UM0vuBLk1QEUVubY=.b578ce93-be1c-43a5-b372-0f0edf763c7f@github.com>

On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7990

From naoto at openjdk.java.net  Mon Mar 28 17:02:33 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 17:02:33 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v4]
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <dLdheuh0Rs-gl2KQuKJ_VFa2L3pha2ss0-ZGVJP9Su8=.9de7e833-7f2f-4df1-8471-39a55d4ea999@github.com>

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

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

  New unit test. IllegalArgumentException.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7947/files
  - new: https://git.openjdk.java.net/jdk/pull/7947/files/b4d040af..9d9d3a69

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=02-03

  Stats: 87 lines in 2 files changed: 83 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7947.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947

PR: https://git.openjdk.java.net/jdk/pull/7947

From lancea at openjdk.java.net  Mon Mar 28 17:17:48 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Mar 2022 17:17:48 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v4]
In-Reply-To: <dLdheuh0Rs-gl2KQuKJ_VFa2L3pha2ss0-ZGVJP9Su8=.9de7e833-7f2f-4df1-8471-39a55d4ea999@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <dLdheuh0Rs-gl2KQuKJ_VFa2L3pha2ss0-ZGVJP9Su8=.9de7e833-7f2f-4df1-8471-39a55d4ea999@github.com>
Message-ID: <qoc4SiI0UoxGFfvQsKvcTPc32Uq-4RMPeyRBxNfichw=.6107b1bd-57df-4b9d-8baa-1f2ab99f519b@github.com>

On Mon, 28 Mar 2022 17:02:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   New unit test. IllegalArgumentException.

Changes look fine.

I would suggest adding a comment describing the new tests.  Also one additional suggestion below

test/jdk/java/util/Locale/TestOf.java line 79:

> 77:     @Test (expectedExceptions = IllegalArgumentException.class)
> 78:     public void test_IAE() {
> 79:         Locale.of("en", "", "", "", "");

I would consider using `assertThrows(IllegalArgumentException.class, () -> Locale.of("en", "", "", "", "")); ` instead of  the expectedExceptions annotation element as it is the preferred way forward

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7947

From achung at openjdk.java.net  Mon Mar 28 18:35:54 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 18:35:54 GMT
Subject: <i18n dev> Integrated: 8280400: JDK 19 L10n resource files update -
 msgdrop 10
In-Reply-To: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
References: <j_gmZyktvH-GWuMkafj3EZ5yMPPnU76g5J2u2TffauA=.1f1f575b-61e7-4015-a4a2-b6c551ab4dec@github.com>
Message-ID: <Gltjkc_Ybexl1S5THR_ItVyUAyld7nfA_h8fTuf8qqQ=.875739c6-22bf-4338-8e20-3e6e1b090140@github.com>

On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung <achung at openjdk.org> wrote:

> msg drop for jdk19, Mar 9, 2022

This pull request has now been integrated.

Changeset: c0aecd15
Author:    Alisen Chung <achung at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0aecd15ae8d7abf37901f785fccaff2317c3b23
Stats:     11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod

8280400: JDK 19 L10n resource files update - msgdrop 10

Reviewed-by: naoto, kizune

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

PR: https://git.openjdk.java.net/jdk/pull/7765

From naoto at openjdk.java.net  Mon Mar 28 18:51:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 18:51:30 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v5]
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <GwpaKceKRfNMkMz3cXQ4rqn0J1O_gNpTey5llFbF1Ik=.ef346c88-4d8a-48c1-bbdc-b34c7bc9effc@github.com>

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

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

  Refined test cases

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7947/files
  - new: https://git.openjdk.java.net/jdk/pull/7947/files/9d9d3a69..86c7b586

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=03-04

  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7947.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Mon Mar 28 18:51:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 18:51:31 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v4]
In-Reply-To: <qoc4SiI0UoxGFfvQsKvcTPc32Uq-4RMPeyRBxNfichw=.6107b1bd-57df-4b9d-8baa-1f2ab99f519b@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <dLdheuh0Rs-gl2KQuKJ_VFa2L3pha2ss0-ZGVJP9Su8=.9de7e833-7f2f-4df1-8471-39a55d4ea999@github.com>
 <qoc4SiI0UoxGFfvQsKvcTPc32Uq-4RMPeyRBxNfichw=.6107b1bd-57df-4b9d-8baa-1f2ab99f519b@github.com>
Message-ID: <WxxPi9TABFludh6vQj-EpTiF7iTx1ffdneUTiWm84Es=.4b724a3d-6c47-4aed-b7c5-2ed47f9f7d5b@github.com>

On Mon, 28 Mar 2022 17:13:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   New unit test. IllegalArgumentException.
>
> test/jdk/java/util/Locale/TestOf.java line 79:
> 
>> 77:     @Test (expectedExceptions = IllegalArgumentException.class)
>> 78:     public void test_IAE() {
>> 79:         Locale.of("en", "", "", "", "");
> 
> I would consider using `assertThrows(IllegalArgumentException.class, () -> Locale.of("en", "", "", "", "")); ` instead of  the expectedExceptions annotation element as it is the preferred way forward

Thanks. Modified as suggested.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From lancea at openjdk.java.net  Mon Mar 28 19:13:48 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 28 Mar 2022 19:13:48 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v5]
In-Reply-To: <GwpaKceKRfNMkMz3cXQ4rqn0J1O_gNpTey5llFbF1Ik=.ef346c88-4d8a-48c1-bbdc-b34c7bc9effc@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <GwpaKceKRfNMkMz3cXQ4rqn0J1O_gNpTey5llFbF1Ik=.ef346c88-4d8a-48c1-bbdc-b34c7bc9effc@github.com>
Message-ID: <QXjvskvNq7D6u20eungIUxVYWBNM3d58dSF96eUc8HI=.d537edc6-8c83-4003-aa92-2ddb64a7d26a@github.com>

On Mon, 28 Mar 2022 18:51:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined test cases

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From rriggs at openjdk.java.net  Mon Mar 28 21:09:43 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 28 Mar 2022 21:09:43 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v3]
In-Reply-To: <hMnD7rywZCJIk-qk3y_ILTZ7qu1ZnVCfuz308rYtxyI=.969e7735-40c1-40e3-a891-a87f6b55d586@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>
 <IYnWChv0pLYc6MJpLkLhHwNvAtTKZcCiQoyy6LpfMQo=.d345951b-8a67-4b36-9727-e143f99af03e@github.com>
 <hMnD7rywZCJIk-qk3y_ILTZ7qu1ZnVCfuz308rYtxyI=.969e7735-40c1-40e3-a891-a87f6b55d586@github.com>
Message-ID: <E-xU-IcAQuOku_L4eRbPPMyEIkNlOG9PaNIsP5RE7nM=.4e151ca6-3e9f-43bd-a7d1-ec97738c665f@github.com>

On Mon, 28 Mar 2022 16:00:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 819:
>> 
>>> 817:      * @since 19
>>> 818:      */
>>> 819:     public static Locale of(String... fields) {
>> 
>> Arguably, there?should?be `Locale.of`?overloads taking?0 to?4?arguments, so?that it?s?not?necessary to?box the?fields in?a?`String`?array.
>
> While it is true for completeness, I would limit the addition of new method as little as possible, because there are already several ways to obtain a Locale object.

As with other varargs method calls, it is possible to pass an array with the values.
I think it would be useful to describe the arguments as using the varargs nomenclature and indicate
the values are in the array.  For example, the `java.util.List.of(E... elements)` method is explicit 
about the array. Anther API using varargs EnumSet.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From achung at openjdk.java.net  Mon Mar 28 21:30:15 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 21:30:15 GMT
Subject: <i18n dev> RFR: 8283806: [BACKOUT] JDK 19 L10n resource files
 update - msgdrop 10
Message-ID: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>

This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

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

Commit messages:
 - Revert "8280400: JDK 19 L10n resource files update - msgdrop 10"

Changes: https://git.openjdk.java.net/jdk/pull/8005/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8005&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283806
  Stats: 11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8005.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8005/head:pull/8005

PR: https://git.openjdk.java.net/jdk/pull/8005

From kcr at openjdk.java.net  Mon Mar 28 21:30:16 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 28 Mar 2022 21:30:16 GMT
Subject: <i18n dev> RFR: 8283806: [BACKOUT] JDK 19 L10n resource files
 update - msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <FaqSreLXyYzhr0FYhkqcq8UW9Dn8RNNX0C7kb7-RGkA=.ba08bc41-383f-4e23-8103-7f0ef391df19@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

I confirm that this is an exact backout of [JDK-8280400](https://bugs.openjdk.java.net/browse/JDK-8280400).

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

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/8005

From naoto at openjdk.java.net  Mon Mar 28 22:16:43 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 22:16:43 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v6]
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <yM50SY2tPRRNHCK4OOZx03HXTyVB78D5m-9zK1fZggE=.54eb37e3-b5fa-4287-a092-63ce2bc2f503@github.com>

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

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

  Added an @apiNote describing the single array argument

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7947/files
  - new: https://git.openjdk.java.net/jdk/pull/7947/files/86c7b586..b1d36b52

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Mon Mar 28 22:16:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 22:16:44 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v3]
In-Reply-To: <E-xU-IcAQuOku_L4eRbPPMyEIkNlOG9PaNIsP5RE7nM=.4e151ca6-3e9f-43bd-a7d1-ec97738c665f@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <fNEGpkJWAQR9qoHEdb9oprkGCw21LeUF9RCNu5zSmtA=.55f85e7e-90ef-4a4c-97c6-2b90ceb4f4dc@github.com>
 <IYnWChv0pLYc6MJpLkLhHwNvAtTKZcCiQoyy6LpfMQo=.d345951b-8a67-4b36-9727-e143f99af03e@github.com>
 <hMnD7rywZCJIk-qk3y_ILTZ7qu1ZnVCfuz308rYtxyI=.969e7735-40c1-40e3-a891-a87f6b55d586@github.com>
 <E-xU-IcAQuOku_L4eRbPPMyEIkNlOG9PaNIsP5RE7nM=.4e151ca6-3e9f-43bd-a7d1-ec97738c665f@github.com>
Message-ID: <o4D-tTddnl1MWppcbgxJBvifSsTJ-ZxoV8bvg9Vq02c=.101ee9b2-6ac5-4389-913b-cd24fcd890e4@github.com>

On Mon, 28 Mar 2022 21:06:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> While it is true for completeness, I would limit the addition of new method as little as possible, because there are already several ways to obtain a Locale object.
>
> As with other varargs method calls, it is possible to pass an array with the values.
> I think it would be useful to describe the arguments as using the varargs nomenclature and indicate
> the values are in the array.  For example, the `java.util.List.of(E... elements)` method is explicit 
> about the array. Anther API using varargs EnumSet.

Added the explanation following the `List.of(E... elements)` javadoc.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Mon Mar 28 22:44:36 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 28 Mar 2022 22:44:36 GMT
Subject: <i18n dev> RFR: 8283806: [BACKOUT] JDK 19 L10n resource files
 update - msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <jtwpNmcgdU1P5vo-z1GqeBzGlkydOcOsamki-j7cdAA=.d2087435-7f1a-4a78-b8c5-91d4577745e5@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8005

From achung at openjdk.java.net  Mon Mar 28 23:40:44 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Mon, 28 Mar 2022 23:40:44 GMT
Subject: <i18n dev> Integrated: 8283806: [BACKOUT] JDK 19 L10n resource
 files update - msgdrop 10
In-Reply-To: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
References: <SySDA3JbeF2IsVanlbzlx869OeKjSjhmIsQBKxE2gTw=.1e570a24-0d5e-440f-94a9-d5dafd153fec@github.com>
Message-ID: <zrorEpgQ5H2ZmwvH02RY-vMNitbxb4vcyk7W_pXhThw=.dd16b716-2dc8-42e6-b70e-7b58196a88de@github.com>

On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23.

This pull request has now been integrated.

Changeset: 634800a5
Author:    Alisen Chung <achung at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/634800a536e7f9d148a4caa2663a60a2c5fc4929
Stats:     11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod

8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10

Reviewed-by: kcr, naoto

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

PR: https://git.openjdk.java.net/jdk/pull/8005

From redestad at openjdk.java.net  Tue Mar 29 09:35:48 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 29 Mar 2022 09:35:48 GMT
Subject: <i18n dev> RFR: 8283781: Avoid allocating unused lastRulesCaches
In-Reply-To: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>
References: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>
Message-ID: <YWbhil-tBvwRdM4GuOp-YVLZJBYR1QZl_AQcHwVgkZw=.128b8b41-b07b-43b0-a994-45e4d0d9e94d@github.com>

On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.

Thanks for reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/7990

From redestad at openjdk.java.net  Tue Mar 29 09:35:48 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 29 Mar 2022 09:35:48 GMT
Subject: <i18n dev> Integrated: 8283781: Avoid allocating unused
 lastRulesCaches
In-Reply-To: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>
References: <K98uvwMi-S3odyLENmakhZ2g_SWzOqJINsI6IcEIasQ=.c0b652fa-8d7e-49ca-b662-72faa8749d85@github.com>
Message-ID: <TwU5ywFfW-tN4khQr47k0_X3MXrbBxNSJMuJXfSnMrc=.2e001313-a5c6-4167-b855-961f3df6cbe1@github.com>

On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily.

This pull request has now been integrated.

Changeset: 0e788e0e
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0e788e0ecbf44f1feee817fe22123a8523da5ee3
Stats:     16 lines in 1 file changed: 9 ins; 2 del; 5 mod

8283781: Avoid allocating unused lastRulesCaches

Reviewed-by: rriggs, naoto

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

PR: https://git.openjdk.java.net/jdk/pull/7990

From rriggs at openjdk.java.net  Tue Mar 29 14:55:17 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 29 Mar 2022 14:55:17 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v6]
In-Reply-To: <yM50SY2tPRRNHCK4OOZx03HXTyVB78D5m-9zK1fZggE=.54eb37e3-b5fa-4287-a092-63ce2bc2f503@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <yM50SY2tPRRNHCK4OOZx03HXTyVB78D5m-9zK1fZggE=.54eb37e3-b5fa-4287-a092-63ce2bc2f503@github.com>
Message-ID: <eewWq3Jq0X7ncvABfFT6j6_0CE1-ojYt1BOYBwQLj4Q=.70629c1b-99f6-4459-8ea6-33a0796caf21@github.com>

On Mon, 28 Mar 2022 22:16:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added an @apiNote describing the single array argument

src/java.base/share/classes/sun/util/locale/provider/JRELocaleConstants.java line 38:

> 36:  */
> 37: public class JRELocaleConstants {
> 38:     public static final Locale JA_JP_JP = Locale.forLanguageTag("ja-JP-x-lvariant-JP");

You might use the new factory here.

src/java.base/share/classes/sun/util/resources/LocaleData.java line 249:

> 247:         // TODO: avoid hard-coded Locales
> 248:         private static final Set<Locale> JAVA_BASE_LOCALES
> 249:             = Set.of(Locale.ROOT, Locale.ENGLISH, Locale.US, Locale.forLanguageTag("en-US-POSIX"));

Use new factory?

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Tue Mar 29 21:28:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 29 Mar 2022 21:28:44 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v7]
In-Reply-To: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
Message-ID: <XdV6SN-DorYpb-wZb39-RAGHxWHFXZZ7BQCspEq0TTE=.bc4b7909-5da9-4fb0-bb45-f988e74eaf57@github.com>

> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.

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

  Changed from var-args to conventional args. Reflected suggestions.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7947/files
  - new: https://git.openjdk.java.net/jdk/pull/7947/files/b1d36b52..8ac9d11d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=05-06

  Stats: 132 lines in 4 files changed: 76 ins; 3 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7947.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947

PR: https://git.openjdk.java.net/jdk/pull/7947

From naoto at openjdk.java.net  Tue Mar 29 21:34:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 29 Mar 2022 21:34:52 GMT
Subject: <i18n dev> RFR: 8282819: Deprecate Locale class constructors
 [v7]
In-Reply-To: <XdV6SN-DorYpb-wZb39-RAGHxWHFXZZ7BQCspEq0TTE=.bc4b7909-5da9-4fb0-bb45-f988e74eaf57@github.com>
References: <kgGsXn8cR-ZQJLpSUVwX3UZkTPH1HuHcHDgiVrltYC0=.33f628ad-e95b-4b32-a603-8934ccb453ed@github.com>
 <XdV6SN-DorYpb-wZb39-RAGHxWHFXZZ7BQCspEq0TTE=.bc4b7909-5da9-4fb0-bb45-f988e74eaf57@github.com>
Message-ID: <KXngYrTuw4LYrfZjACXbSV-u0kH3PppD42TpennrNsA=.fb0cd8e5-ba59-4b45-9261-78c511ef7e9d@github.com>

On Tue, 29 Mar 2022 21:28:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed from var-args to conventional args. Reflected suggestions.

Per a comment in the CSR discussion (https://bugs.openjdk.java.net/browse/JDK-8283478?focusedCommentId=14485037&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14485037), I changed the arguments to var-args to conventional ones.

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

PR: https://git.openjdk.java.net/jdk/pull/7947

From achung at openjdk.java.net  Wed Mar 30 00:54:29 2022
From: achung at openjdk.java.net (Alisen Chung)
Date: Wed, 30 Mar 2022 00:54:29 GMT
Subject: <i18n dev> RFR: 8283805: [REDO] JDK 19 L10n resource files update -
 msgdrop 10
Message-ID: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>

redo of 8280400

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

Commit messages:
 - 8280400: JDK 19 L10n resource files update - msgdrop 10

Changes: https://git.openjdk.java.net/jdk/pull/8026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8026&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283805
  Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8026/head:pull/8026

PR: https://git.openjdk.java.net/jdk/pull/8026

From kcr at openjdk.java.net  Wed Mar 30 11:35:38 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 30 Mar 2022 11:35:38 GMT
Subject: <i18n dev> RFR: 8283805: [REDO] JDK 19 L10n resource files
 update - msgdrop 10
In-Reply-To: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
References: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
Message-ID: <EnIpfAYY92S_YJGTVXtEYAlGCdqtzUcbzEmSV1_Zduo=.eb6608f2-1158-474a-80bb-118baf99af89@github.com>

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> redo of 8280400

Since this is identical to the original fix, I would expect the same Tier2 test failure as reported in [JDK-8283804](https://bugs.openjdk.java.net/browse/JDK-8283804).

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

PR: https://git.openjdk.java.net/jdk/pull/8026

From redestad at openjdk.java.net  Wed Mar 30 12:14:56 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 30 Mar 2022 12:14:56 GMT
Subject: <i18n dev> RFR: 8283996: Reduce cost of year and month calculations
Message-ID: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>

A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups.

Baseline:

Benchmark                                            Mode  Cnt   Score   Error   Units
GetYearBench.getYearFromMillisZoneOffset            thrpt   15  18.492 ? 0.017  ops/ms
GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.121 ? 0.135  ops/ms
GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  18.936 ? 0.012  ops/ms
GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15   9.283 ? 0.222  ops/ms

Patched:

Benchmark                                            Mode  Cnt   Score   Error   Units
GetYearBench.getYearFromMillisZoneOffset            thrpt   15  20.931 ? 0.013  ops/ms
GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.858 ? 0.167  ops/ms
GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  20.923 ? 0.017  ops/ms
GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15  10.028 ? 0.182  ops/ms


Testing: java.time tests locally, CI tier1+2 ongoing.

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

Commit messages:
 - Reduce cost of year and month calculations

Changes: https://git.openjdk.java.net/jdk/pull/8039/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8039&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283996
  Stats: 12 lines in 2 files changed: 6 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8039/head:pull/8039

PR: https://git.openjdk.java.net/jdk/pull/8039

From naoto at openjdk.java.net  Wed Mar 30 15:48:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 30 Mar 2022 15:48:38 GMT
Subject: <i18n dev> RFR: 8283805: [REDO] JDK 19 L10n resource files
 update - msgdrop 10
In-Reply-To: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
References: <YVEmLu-_cOvRQdHfANi62d5Oh6Aba_Kpy4BhXGRBFSk=.9a367c1b-aa8b-46bf-85fd-a00292cbaea0@github.com>
Message-ID: <a41NNQJWMB7s3ZKC9Oc0wOR6djcVyJwClVqybrBHmto=.7cabbe09-19b7-414f-8843-c2490eab98ea@github.com>

On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> redo of 8280400

I believe `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties` and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to the l10n changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8026

From bpb at openjdk.java.net  Wed Mar 30 16:11:38 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 30 Mar 2022 16:11:38 GMT
Subject: <i18n dev> RFR: 8283996: Reduce cost of year and month
 calculations
In-Reply-To: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
References: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
Message-ID: <E7KVNAr6BwJxLd9oJHSlL--6YW0GJF3HFsvXEfvjR14=.4ec5edf6-8cfd-45cb-a564-e43c0e195d0c@github.com>

On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups.
> 
> Baseline:
> 
> Benchmark                                            Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset            thrpt   15  18.492 ? 0.017  ops/ms
> GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.121 ? 0.135  ops/ms
> GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  18.936 ? 0.012  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15   9.283 ? 0.222  ops/ms
> 
> Patched:
> 
> Benchmark                                            Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset            thrpt   15  20.931 ? 0.013  ops/ms
> GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.858 ? 0.167  ops/ms
> GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  20.923 ? 0.017  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15  10.028 ? 0.182  ops/ms
> 
> 
> Testing: java.time tests locally, CI tier1+2 ongoing.

Looks all right assuming tests pass.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8039

From naoto at openjdk.java.net  Wed Mar 30 16:52:59 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 30 Mar 2022 16:52:59 GMT
Subject: <i18n dev> RFR: 8283842:
 TestZoneTextPrinterParser.test_roundTripAtOverlap fails:
 DateTimeParseException
Message-ID: <C5mT9Hs3AG7Ifwd9_aTxnmxv-B4AYtFjuV4b6nofEoo=.02f1b1e4-6af5-48a1-9201-72ffd5bc6e24@github.com>

Fixes test failures caused by depending on the default locale. Specifying explicit `Locale.US` will do.

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

Commit messages:
 - 8283842: TestZoneTextPrinterParser.test_roundTripAtOverlap fails: DateTimeParseException

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

PR: https://git.openjdk.java.net/jdk/pull/8045

From redestad at openjdk.java.net  Wed Mar 30 17:03:34 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 30 Mar 2022 17:03:34 GMT
Subject: <i18n dev> RFR: 8283996: Reduce cost of year and month
 calculations
In-Reply-To: <E7KVNAr6BwJxLd9oJHSlL--6YW0GJF3HFsvXEfvjR14=.4ec5edf6-8cfd-45cb-a564-e43c0e195d0c@github.com>
References: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
 <E7KVNAr6BwJxLd9oJHSlL--6YW0GJF3HFsvXEfvjR14=.4ec5edf6-8cfd-45cb-a564-e43c0e195d0c@github.com>
Message-ID: <Eg-2cvoOnJEa7xvCZ_fYkBfTBRn3SDCIrCLEqjcy5fU=.ecd98c47-a88c-485b-9d73-7b84994f849f@github.com>

On Wed, 30 Mar 2022 16:08:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Looks all right assuming tests pass.

Thanks! Tier1+2 testing passed.

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

PR: https://git.openjdk.java.net/jdk/pull/8039

From iris at openjdk.java.net  Wed Mar 30 17:12:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 30 Mar 2022 17:12:40 GMT
Subject: <i18n dev> RFR: 8283842:
 TestZoneTextPrinterParser.test_roundTripAtOverlap fails:
 DateTimeParseException
In-Reply-To: <C5mT9Hs3AG7Ifwd9_aTxnmxv-B4AYtFjuV4b6nofEoo=.02f1b1e4-6af5-48a1-9201-72ffd5bc6e24@github.com>
References: <C5mT9Hs3AG7Ifwd9_aTxnmxv-B4AYtFjuV4b6nofEoo=.02f1b1e4-6af5-48a1-9201-72ffd5bc6e24@github.com>
Message-ID: <_9oBG0kA1bJ0HooNdvBt3luwxUmWlAE-k1PzTsaS9cY=.1e0d8ecf-1938-47db-9a8a-b7e8ab9a9eff@github.com>

On Wed, 30 Mar 2022 16:46:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixes test failures caused by depending on the default locale. Specifying explicit `Locale.US` will do.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8045

From rriggs at openjdk.java.net  Wed Mar 30 18:02:39 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 30 Mar 2022 18:02:39 GMT
Subject: <i18n dev> RFR: 8283842:
 TestZoneTextPrinterParser.test_roundTripAtOverlap fails:
 DateTimeParseException
In-Reply-To: <C5mT9Hs3AG7Ifwd9_aTxnmxv-B4AYtFjuV4b6nofEoo=.02f1b1e4-6af5-48a1-9201-72ffd5bc6e24@github.com>
References: <C5mT9Hs3AG7Ifwd9_aTxnmxv-B4AYtFjuV4b6nofEoo=.02f1b1e4-6af5-48a1-9201-72ffd5bc6e24@github.com>
Message-ID: <Ekn2xpJLSolq_EZsjnZkr7AVbmTQP5rF8Q8Fo49wp_0=.f8ab20d6-d2d2-4c0c-868a-bee9a2795b55@github.com>

On Wed, 30 Mar 2022 16:46:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixes test failures caused by depending on the default locale. Specifying explicit `Locale.US` will do.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8045

From scolebourne at openjdk.java.net  Wed Mar 30 19:11:39 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 30 Mar 2022 19:11:39 GMT
Subject: <i18n dev> RFR: 8283996: Reduce cost of year and month
 calculations
In-Reply-To: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
References: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
Message-ID: <8A2--PpHwO1GgHz1_6LYloWYKTrlNYia_kl30ZBEPqU=.4319d914-b329-49cb-9936-8961474e6057@github.com>

On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups.
> 
> Baseline:
> 
> Benchmark                                            Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset            thrpt   15  18.492 ? 0.017  ops/ms
> GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.121 ? 0.135  ops/ms
> GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  18.936 ? 0.012  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15   9.283 ? 0.222  ops/ms
> 
> Patched:
> 
> Benchmark                                            Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset            thrpt   15  20.931 ? 0.013  ops/ms
> GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.858 ? 0.167  ops/ms
> GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  20.923 ? 0.017  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15  10.028 ? 0.182  ops/ms
> 
> 
> Testing: java.time tests locally, CI tier1+2 ongoing.

I'm happy, based on the assertion that it produces the same result and is faster.

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

Marked as reviewed by scolebourne (Author).

PR: https://git.openjdk.java.net/jdk/pull/8039

From scolebourne at openjdk.java.net  Wed Mar 30 19:13:36 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 30 Mar 2022 19:13:36 GMT
Subject: <i18n dev> RFR: 8283842:
 TestZoneTextPrinterParser.test_roundTripAtOverlap fails:
 DateTimeParseException
In-Reply-To: <C5mT9Hs3AG7Ifwd9_aTxnmxv-B4AYtFjuV4b6nofEoo=.02f1b1e4-6af5-48a1-9201-72ffd5bc6e24@github.com>
References: <C5mT9Hs3AG7Ifwd9_aTxnmxv-B4AYtFjuV4b6nofEoo=.02f1b1e4-6af5-48a1-9201-72ffd5bc6e24@github.com>
Message-ID: <3Wk-LQz1rZR4XwqZX-04hy2hweNoXCq8VLS-Ry_urjM=.3395e29f-78ce-466e-9a45-2a25fad50170@github.com>

On Wed, 30 Mar 2022 16:46:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixes test failures caused by depending on the default locale. Specifying explicit `Locale.US` will do.

Marked as reviewed by scolebourne (Author).

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

PR: https://git.openjdk.java.net/jdk/pull/8045

From naoto at openjdk.java.net  Wed Mar 30 19:50:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 30 Mar 2022 19:50:40 GMT
Subject: <i18n dev> RFR: 8283996: Reduce cost of year and month
 calculations
In-Reply-To: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
References: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
Message-ID: <EUCUTyfqCwf9IRCqWBjUpLomRXKZK501i308z8elTe4=.14db409c-f1d8-49af-8fff-b0d0a220701c@github.com>

On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups.
> 
> Baseline:
> 
> Benchmark                                            Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset            thrpt   15  18.492 ? 0.017  ops/ms
> GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.121 ? 0.135  ops/ms
> GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  18.936 ? 0.012  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15   9.283 ? 0.222  ops/ms
> 
> Patched:
> 
> Benchmark                                            Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset            thrpt   15  20.931 ? 0.013  ops/ms
> GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.858 ? 0.167  ops/ms
> GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  20.923 ? 0.017  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15  10.028 ? 0.182  ops/ms
> 
> 
> Testing: java.time tests locally, CI tier1+2 ongoing.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8039

From rriggs at openjdk.java.net  Wed Mar 30 22:19:33 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 30 Mar 2022 22:19:33 GMT
Subject: <i18n dev> RFR: 8283996: Reduce cost of year and month
 calculations
In-Reply-To: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
References: <JotaDr4BiIepV6lDm4nyxOLqYwOdBWUdV2NxLHcylDA=.47158c71-da09-44f1-92a3-347c389f9838@github.com>
Message-ID: <gWDDQinWSxIHCt2Df_BOljdUDgspic2d7h1fZHMYOto=.359481b5-b767-486b-be56-a4bbc1522a2b@github.com>

On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups.
> 
> Baseline:
> 
> Benchmark                                            Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset            thrpt   15  18.492 ? 0.017  ops/ms
> GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.121 ? 0.135  ops/ms
> GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  18.936 ? 0.012  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15   9.283 ? 0.222  ops/ms
> 
> Patched:
> 
> Benchmark                                            Mode  Cnt   Score   Error   Units
> GetYearBench.getYearFromMillisZoneOffset            thrpt   15  20.931 ? 0.013  ops/ms
> GetYearBench.getYearFromMillisZoneRegion            thrpt   15   6.858 ? 0.167  ops/ms
> GetYearBench.getYearFromMillisZoneRegionNormalized  thrpt   15  20.923 ? 0.017  ops/ms
> GetYearBench.getYearFromMillisZoneRegionUTC         thrpt   15  10.028 ? 0.182  ops/ms
> 
> 
> Testing: java.time tests locally, CI tier1+2 ongoing.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8039