From duke at openjdk.java.net  Wed Jun  1 04:16:35 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 1 Jun 2022 04:16:35 GMT
Subject: <i18n dev> RFR: 8287340: Refactor old code using
 StringTokenizer in locale related code
In-Reply-To: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
Message-ID: <RRoC2pBFKw9ok-hQaJtmhlDg2Lhwmm98ptM5FfBEhZQ=.6660fbcf-e88c-45bd-992c-6769717b094b@github.com>

On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 181:

> 179:                 .toArray(Locale[]::new);
> 180:         }
> 181:         return AVAILABLE_LOCALES;

This?should probably clone?the?cached?array:
Suggestion:

        return AVAILABLE_LOCALES.clone();


Matching?what `JRELocaleProviderAdapter`?does[^1], since?there?s no?guarantee that?the?result of?`getAvailableLocales()` won?t?be?mutated.

[^1]: https://github.com/openjdk/jdk/blob/6b1169e266b9d21864f886ef574dd64116fa2cb0/src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java#L430-L439

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

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

From duke at openjdk.java.net  Wed Jun  1 13:32:36 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Wed, 1 Jun 2022 13:32:36 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v6]
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:

 - 8285838: Cleanup of trailing whitespace
 - 8285838: Corrected month comparison check for TZ DST

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/9e3b1bb4..87832663

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

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

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

From duke at openjdk.java.net  Wed Jun  1 13:36:33 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Wed, 1 Jun 2022 13:36:33 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v5]
In-Reply-To: <dbQFYDugzX8zNINu-4WJ6fAoSoTAdXa72GqkqKuBCCQ=.28a3eb2a-4d60-4dac-bc84-f0386dfad30f@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <7SpDwS0sWsYuaiBdJqhhqUPEyc7gcBcL4mExUW3RE_4=.a62ad8f9-7fe9-4d45-92b9-74222698e845@github.com>
 <dbQFYDugzX8zNINu-4WJ6fAoSoTAdXa72GqkqKuBCCQ=.28a3eb2a-4d60-4dac-bc84-f0386dfad30f@github.com>
Message-ID: <0gdQwqgXz3SqAZXXyMfFphDyae6uxLYZyH0aKQ14Ljo=.3be034af-ec1b-4ec2-bcd6-769240c9fb0e@github.com>

On Tue, 31 May 2022 22:34:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285838: Corrected month comparison check for TZ DST
>
> I tried out your patch on my local Linux machine, but the new test failed with the following exception:
> 
> ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
> REASON: User specified action: run main/othervm CustomTzIDCheckDST 
> TIME:   1.564 seconds
> messages:
> command: main CustomTzIDCheckDST
> reason: User specified action: run main/othervm CustomTzIDCheckDST 
> Mode: othervm [/othervm specified]
> elapsed time (seconds): 1.564
> configuration:
> STDOUT:
> Command line: [/home/nsato/projects/jdk/git/jdk/build/linux-x64/images/jdk/bin/java -cp /home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/java/util/TimeZone/CustomTzIDCheckDST.d:/home/nsato/projects/jdk/git/jdk/open/test/jdk/java/util/TimeZone:/home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/test/lib:/home/nsato/projects/jdk/git/jdk/open/test/lib:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/javatest.jar:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/jtreg.jar CustomTzIDCheckDST runTZTest ]
> [2022-05-31T22:27:05.958567816Z] Gathering output for process 14771
> [2022-05-31T22:27:06.635595481Z] Waiting for completion for process 14771
> [2022-05-31T22:27:06.635976964Z] Waiting for completion finished for process 14771
> Output and diagnostic info for process 14771 was saved into 'pid-14771-output.log'
> [2022-05-31T22:27:06.663087767Z] Waiting for completion for process 14771
> [2022-05-31T22:27:06.663360403Z] Waiting for completion finished for process 14771
> [2022-05-31T22:27:06.663754609Z] Waiting for completion for process 14771
> [2022-05-31T22:27:06.663869034Z] Waiting for completion finished for process 14771
> STDERR:
>  stdout: [];
>  stderr: [Exception in thread "main" java.time.DateTimeException: Invalid ID for offset-based ZoneId: GMT-22:00
> 	at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:436)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:406)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:358)
> 	at java.base/java.time.ZoneId.of(ZoneId.java:314)
> 	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:581)
> 	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
> 	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:570)
> 	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
> 	at java.base/java.time.ZoneId.systemDefault(ZoneId.java:274)
> 	at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:64)
> 	at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:51)
> Caused by: java.time.DateTimeException: Zone offset hours not in valid range: value -22 is not in the range -18 to 18
> 	at java.base/java.time.ZoneOffset.validate(ZoneOffset.java:373)
> 	at java.base/java.time.ZoneOffset.ofHoursMinutesSeconds(ZoneOffset.java:326)
> 	at java.base/java.time.ZoneOffset.of(ZoneOffset.java:257)
> 	at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:430)
> 	... 10 more
> ]
>  exitValue = 1
> 
> java.lang.RuntimeException: Expected to get exit value of [0]
> 
> 	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:489)
> 	at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:49)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:1585)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
> 
> JavaTest Message: shutting down test
> 
> STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

Hi @naotoj ,
I am unable to reproduce the above error you are seeing, and it is passing on my linux machine. What is the system default timezone on your local machine? Wondering if it will help me see what you are seeing (even though the timezone should be overriden via the TZ variable). Looks like the test is not even reaching the checks and failing at the point where its simply trying to retrieve the current time.

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

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

From naoto at openjdk.java.net  Wed Jun  1 16:34:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 16:34:44 GMT
Subject: <i18n dev> RFR: 8287340: Refactor old code using
 StringTokenizer in locale related code [v2]
In-Reply-To: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
Message-ID: <fpyyN5DzjtBpa8DWu1FBS_Tw0oLxrkXBABB6reSA2FA=.4ac90777-442a-4410-88ae-6256d0e18278@github.com>

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

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

  Removed unnecessary clone() call

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8960/files
  - new: https://git.openjdk.java.net/jdk/pull/8960/files/6b1169e2..d1b00f10

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

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

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

From naoto at openjdk.java.net  Wed Jun  1 16:39:33 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 16:39:33 GMT
Subject: <i18n dev> RFR: 8287340: Refactor old code using
 StringTokenizer in locale related code [v2]
In-Reply-To: <RRoC2pBFKw9ok-hQaJtmhlDg2Lhwmm98ptM5FfBEhZQ=.6660fbcf-e88c-45bd-992c-6769717b094b@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
 <RRoC2pBFKw9ok-hQaJtmhlDg2Lhwmm98ptM5FfBEhZQ=.6660fbcf-e88c-45bd-992c-6769717b094b@github.com>
Message-ID: <iZM1ghp3dm3o8W0FsSjnei9G9GzItEQ5tjBuUsIhTJI=.b85e1eb3-6a32-4a1a-bc47-4719372db764@github.com>

On Wed, 1 Jun 2022 04:10:03 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:
>> 
>>   Removed unnecessary clone() call
>
> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 181:
> 
>> 179:                 .toArray(Locale[]::new);
>> 180:         }
>> 181:         return AVAILABLE_LOCALES;
> 
> This?should probably clone?the?cached?array:
> Suggestion:
> 
>         return AVAILABLE_LOCALES.clone();
> 
> 
> Matching?what `JRELocaleProviderAdapter`?does[^1], since?there?s no?guarantee that?the?result of?`getAvailableLocales()` won?t?be?mutated.
> 
> [^1]: https://github.com/openjdk/jdk/blob/6b1169e266b9d21864f886ef574dd64116fa2cb0/src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java#L430-L439

Thanks for your comments. In fact, `clone()` in `JRELocaleProviderAdapter` is not necessary, as it will be subsumed into `Locale.getAvailableLocales()` and other `getAvailableLocales()` methods in locale sensitives services (such as `DateFormat`) where they are defensively cloned. Removed this `clone()` invocation.

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

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

From smarks at openjdk.java.net  Wed Jun  1 17:44:24 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 1 Jun 2022 17:44:24 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <IhiEBcMA2Zj0IWKO4jNpbCdAYbNvKP-GlA2bcbU7Yo0=.670eea02-4f1a-48db-996b-1cec9c1438e0@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks.

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

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

From naoto at openjdk.java.net  Wed Jun  1 18:23:36 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 18:23:36 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v6]
In-Reply-To: <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
Message-ID: <kUXgFvtwanvyJcAJGensAv2-epjXAvnCNWocxGzn_hg=.75529805-e19a-4964-b545-8c383db5864e@github.com>

On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8285838: Cleanup of trailing whitespace
>  - 8285838: Corrected month comparison check for TZ DST

The machine has `/etc/localtime` pointing to `/usr/share/zoneinfo/GMT`, thus the system zone is `GMT`. However, for some reason, I cannot reproduce it on that machine any longer. Could be some inconsistency in my repo. Will test in our CI system and let you know the result later.

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

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

From naoto at openjdk.java.net  Wed Jun  1 18:31:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 18:31:34 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewed i18n-related changes and they look good. One minor suggestion in `Calendar`, but that can be applied later.

src/java.base/share/classes/java/util/Calendar.java line 2648:

> 2646:             set.add("gregory");
> 2647:             set.add("buddhist");
> 2648:             set.add("japanese");

This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

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

Marked as reviewed by naoto (Reviewer).

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

From bpb at openjdk.java.net  Wed Jun  1 18:42:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 18:42:36 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <dh6Twe_QhgR3NgCROm40Rj2oJfp5V0EseBOq_y5IFUE=.4179a789-9937-4779-83fc-6ba845c17667@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

`java.io` and `java.nio` look all right.

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

Marked as reviewed by bpb (Reviewer).

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

From dfuchs at openjdk.java.net  Thu Jun  2 10:33:19 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 2 Jun 2022 10:33:19 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <pBk0szIsy279wF9Amofquc9RB4SyYy1LkvBmdUdwFNU=.9c320114-bff4-4d0c-91ff-c56827cbf4d1@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Changes to `net` and `http` look good.

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

Marked as reviewed by dfuchs (Reviewer).

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

From naoto at openjdk.java.net  Thu Jun  2 18:09:43 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 2 Jun 2022 18:09:43 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v6]
In-Reply-To: <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
Message-ID: <hFv73VcpIbtvX371j7lSMPKZYTgIDPp0kqHrhMzCFRY=.a0d69f33-d35e-4214-8af6-2a0f2b32c027@github.com>

On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8285838: Cleanup of trailing whitespace
>  - 8285838: Corrected month comparison check for TZ DST

I tried several runs of CI tests and found no failures. Sorry for the false alarm. BTW, now I've looked the test more closely, the test can be simplified by using `SimpleTimeZone`, such as:

 new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0, Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(new Date())

This piece will check the current date is in DST, emulating `TZ=MEZ-1MESZ,M3.5.0,M10.5.0`

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

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

From duke at openjdk.java.net  Thu Jun  2 18:18:44 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Thu, 2 Jun 2022 18:18:44 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v6]
In-Reply-To: <hFv73VcpIbtvX371j7lSMPKZYTgIDPp0kqHrhMzCFRY=.a0d69f33-d35e-4214-8af6-2a0f2b32c027@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
 <hFv73VcpIbtvX371j7lSMPKZYTgIDPp0kqHrhMzCFRY=.a0d69f33-d35e-4214-8af6-2a0f2b32c027@github.com>
Message-ID: <4IqQwf-riLwaRfXuZg2TNxy72i2XnLYkp2rNlpwULS0=.6acd9f9e-80cd-440a-88e1-f4407460b573@github.com>

On Thu, 2 Jun 2022 18:07:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8285838: Cleanup of trailing whitespace
>>  - 8285838: Corrected month comparison check for TZ DST
>
> I tried several runs of CI tests and found no failures. Sorry for the false alarm. BTW, now I've looked the test more closely, the test can be simplified by using `SimpleTimeZone`, such as:
> 
>  new SimpleTimeZone(3600000, "MEZ-1MESZ", Calendar.MARCH, -1, Calendar.SUNDAY, 0, Calendar.OCTOBER, -1, Calendar.SUNDAY, 0).inDaylightTime(new Date())
> 
> This piece will check the current date is in DST, emulating `TZ=MEZ-1MESZ,M3.5.0,M10.5.0`

Hi @naotoj , 
Thanks for revisiting that and confirming it is all good. Initially the problem was brought to my attention through a third party client utilizing this particular TZ code, and that is where we got the basis for the need of the fix, where we are bypassing typical tzdb access to find named Timezones such as "Europe/Belgium" and trying to find the GMT offset and computing the time.

Is the suggestion here to substitute the setting of the TZ environment variable, and simply getting a date based off this `SimpleTimeZone` , so as to bypass the process creation and just have it as a more simpler test? This sounds perfectly fine as long as SimpleTimeZone is have the zone ID setup exactly as the `MEZ-1MESZ,M3.5.0,M10.5.0` indicated. I can try this out ... just wanted to confirm with you how to make use of the above instantiation.

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

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

From naoto at openjdk.java.net  Thu Jun  2 18:33:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 2 Jun 2022 18:33:31 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v6]
In-Reply-To: <4IqQwf-riLwaRfXuZg2TNxy72i2XnLYkp2rNlpwULS0=.6acd9f9e-80cd-440a-88e1-f4407460b573@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
 <hFv73VcpIbtvX371j7lSMPKZYTgIDPp0kqHrhMzCFRY=.a0d69f33-d35e-4214-8af6-2a0f2b32c027@github.com>
 <4IqQwf-riLwaRfXuZg2TNxy72i2XnLYkp2rNlpwULS0=.6acd9f9e-80cd-440a-88e1-f4407460b573@github.com>
Message-ID: <zhbMQ3qxxyCiL5aoDUHp5k8SC0F_wZTcQQOUsYBC-IY=.52014d9a-5cbf-4a1d-9e87-f21952c07e01@github.com>

On Thu, 2 Jun 2022 18:14:55 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

> Is the suggestion here to substitute the setting of the TZ environment variable, and simply getting a date based off this `SimpleTimeZone` , so as to bypass the process creation and just have it as a more simpler test?

No. The test process still has to be spawned with the TZ env variable set. The suggested piece is supposed to replace the following `if` in `runTZTest()` method:

        Calendar calendar = Calendar.getInstance();
        Date time = calendar.getTime();
        // Add 1 since getMonth() starts from 0.
        int month = time.getMonth() + 1;
        ZonedDateTime date = ZonedDateTime.ofInstant(time.toInstant(), ZoneId.systemDefault());
        if ((month > Month.MARCH.getValue() && month < Month.OCTOBER.getValue()) ||
                (month == Month.MARCH.getValue() && date.isAfter(getLastSundayOfMonth(date))) ||
                (month == Month.OCTOBER.getValue() && date.isBefore(getLastSundayOfMonth(date)))) {

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

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

From naoto at openjdk.java.net  Thu Jun  2 18:39:39 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 2 Jun 2022 18:39:39 GMT
Subject: <i18n dev> Integrated: 8287340: Refactor old code using
 StringTokenizer in locale related code
In-Reply-To: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
Message-ID: <2HtX68mSoUnS33W_IV-wkJTMrM_WEmcmqLemJpLBpiM=.115f6c17-ae35-4a01-a3a7-4b8fa350ad9e@github.com>

On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

This pull request has now been integrated.

Changeset: 26d24263
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/26d24263c7db6d8f722afefc975b03cb575fa6ee
Stats:     177 lines in 4 files changed: 6 ins; 62 del; 109 mod

8287340: Refactor old code using StringTokenizer in locale related code

Reviewed-by: iris, joehw

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

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

From duke at openjdk.java.net  Mon Jun  6 13:05:10 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 13:05:10 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
Message-ID: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>

- cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
- `defaultLocale` field is read multiple times in `initDefault()`
- `isoLanguages` is accessed multiple times in `getISOLanguages()`
- `languageTag` is read twice in `toLanguageTag()`

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

Commit messages:
 - 8287860: Revise usage of volatile in j.u.Locale

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

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

From duke at openjdk.java.net  Mon Jun  6 13:23:40 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 6 Jun 2022 13:23:40 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
Message-ID: <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>

On Mon, 6 Jun 2022 12:58:39 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
> - `defaultLocale` field is read multiple times in `initDefault()`
> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`

src/java.base/share/classes/java/util/Locale.java line 2260:

> 2258:      * Calculated hashcode
> 2259:      */
> 2260:     private transient volatile int hashCodeValue;

We can additionally annotate such cache fields with `@Stable` so as to enable constant-folding optimizations from the hotspot JIT.

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

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

From duke at openjdk.java.net  Mon Jun  6 13:30:53 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 13:30:53 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
Message-ID: <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>

On Mon, 6 Jun 2022 13:20:31 GMT, liach <duke at openjdk.java.net> wrote:

>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
>> - `languageTag` is read twice in `toLanguageTag()`
>
> src/java.base/share/classes/java/util/Locale.java line 2260:
> 
>> 2258:      * Calculated hashcode
>> 2259:      */
>> 2260:     private transient volatile int hashCodeValue;
> 
> We can additionally annotate such cache fields with `@Stable` so as to enable constant-folding optimizations from the hotspot JIT.

Shouldn't the fields annotated with `@Stable` be `final` as well?

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

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

From duke at openjdk.java.net  Mon Jun  6 13:36:53 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 6 Jun 2022 13:36:53 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
 <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>
Message-ID: <D1-tfdaeVuBYn-hbEAuchSlpDNnZCX69k0BLWcyiIbs=.ccf96252-9c46-4356-8abd-0a2c98bb7e2c@github.com>

On Mon, 6 Jun 2022 13:28:44 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 2260:
>> 
>>> 2258:      * Calculated hashcode
>>> 2259:      */
>>> 2260:     private transient volatile int hashCodeValue;
>> 
>> We can additionally annotate such cache fields with `@Stable` so as to enable constant-folding optimizations from the hotspot JIT.
>
> Shouldn't the fields annotated with `@Stable` be `final` as well?

These fields can only be written once besides the default values, but they don't have to be written in the static initializer or constructor. So when a non-zero hash code is written, it's cached as if it's a final field. For a zero value, it would always undergo extra calculations like before and write multiple times, but the writes don't matter as it would only write zero, which would not yield false hash code if a previously written 0 value is cached.

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

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

From duke at openjdk.java.net  Mon Jun  6 13:36:54 2022
From: duke at openjdk.java.net (liach)
Date: Mon, 6 Jun 2022 13:36:54 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
In-Reply-To: <D1-tfdaeVuBYn-hbEAuchSlpDNnZCX69k0BLWcyiIbs=.ccf96252-9c46-4356-8abd-0a2c98bb7e2c@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
 <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>
 <D1-tfdaeVuBYn-hbEAuchSlpDNnZCX69k0BLWcyiIbs=.ccf96252-9c46-4356-8abd-0a2c98bb7e2c@github.com>
Message-ID: <7rNyXMbX0726bJEVVqPzt_11kBrVK9Y-d51Z9nmaEeI=.05a0a3eb-f0ad-4085-a2bb-473da56275a3@github.com>

On Mon, 6 Jun 2022 13:32:21 GMT, liach <duke at openjdk.java.net> wrote:

>> Shouldn't the fields annotated with `@Stable` be `final` as well?
>
> These fields can only be written once besides the default values, but they don't have to be written in the static initializer or constructor. So when a non-zero hash code is written, it's cached as if it's a final field. For a zero value, it would always undergo extra calculations like before and write multiple times, but the writes don't matter as it would only write zero, which would not yield false hash code if a previously written 0 value is cached.

> Shouldn't the fields annotated with `@Stable` be `final` as well?

You might have seen `@Stable final` fields. Those are only meaningful for arrays, where such caching happens at each array index. For non-arrays, `@Stable final` is simply equivalent to `final`, and simple `@Stable` acts as what I said above.

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

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

From duke at openjdk.java.net  Mon Jun  6 14:36:03 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 14:36:03 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
 [v2]
In-Reply-To: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
Message-ID: <KibQ69PG_ptQjnEavrpaTSMyg2wJ42lCpJcP_-dmLp8=.0b8f5990-bfe4-47a3-8919-5232bb2a613b@github.com>

> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
> - `defaultLocale` field is read multiple times in `initDefault()`
> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`

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

  8287860: Mark hash fields with @Stable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9041/files
  - new: https://git.openjdk.java.net/jdk/pull/9041/files/d64917f1..d4534346

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

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

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

From duke at openjdk.java.net  Mon Jun  6 14:36:05 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 14:36:05 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
 [v2]
In-Reply-To: <7rNyXMbX0726bJEVVqPzt_11kBrVK9Y-d51Z9nmaEeI=.05a0a3eb-f0ad-4085-a2bb-473da56275a3@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <Zzh_cldIuvKzK_KaOC6MkWTW0IxWbINpnf1X-ZCY_JA=.c424fc77-508b-4f68-a0e4-e34a81b82f4c@github.com>
 <kz6mRyUZG3Pt3Md1NYGlzXOpnT2ocmpTXOiapv0C3wc=.047e3b4d-2124-4e2b-a733-5aba551e78ad@github.com>
 <D1-tfdaeVuBYn-hbEAuchSlpDNnZCX69k0BLWcyiIbs=.ccf96252-9c46-4356-8abd-0a2c98bb7e2c@github.com>
 <7rNyXMbX0726bJEVVqPzt_11kBrVK9Y-d51Z9nmaEeI=.05a0a3eb-f0ad-4085-a2bb-473da56275a3@github.com>
Message-ID: <QtlR0tRSkZ3FRD_PWQyz8F4WLPOJ-KuTl9Kfp2jm0VM=.a59e1d6d-35af-4df3-ae66-cbeabfedbcaf@github.com>

On Mon, 6 Jun 2022 13:34:27 GMT, liach <duke at openjdk.java.net> wrote:

>> These fields can only be written once besides the default values, but they don't have to be written in the static initializer or constructor. So when a non-zero hash code is written, it's cached as if it's a final field. For a zero value, it would always undergo extra calculations like before and write multiple times, but the writes don't matter as it would only write zero, which would not yield false hash code if a previously written 0 value is cached.
>
>> Shouldn't the fields annotated with `@Stable` be `final` as well?
> 
> You might have seen `@Stable final` fields. Those are only meaningful for arrays, where such caching happens at each array index. For non-arrays, `@Stable final` is simply equivalent to `final`, and simple `@Stable` acts as what I said above.

Done!

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

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

From duke at openjdk.java.net  Mon Jun  6 20:37:00 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 20:37:00 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
 [v3]
In-Reply-To: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
Message-ID: <hup7l7k0liltzsNfvr2t5LZICKpaxt_NO1GnxpCQDKA=.f618c8b6-df4f-4892-a1c9-e1f3080b277e@github.com>

> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
> - `defaultLocale` field is read multiple times in `initDefault()`
> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`

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

  8287860: Rename local vars

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9041/files
  - new: https://git.openjdk.java.net/jdk/pull/9041/files/d4534346..454621d4

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

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

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

From naoto at openjdk.java.net  Mon Jun  6 20:37:02 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 20:37:02 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
 [v3]
In-Reply-To: <hup7l7k0liltzsNfvr2t5LZICKpaxt_NO1GnxpCQDKA=.f618c8b6-df4f-4892-a1c9-e1f3080b277e@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <hup7l7k0liltzsNfvr2t5LZICKpaxt_NO1GnxpCQDKA=.f618c8b6-df4f-4892-a1c9-e1f3080b277e@github.com>
Message-ID: <KfTjMp1o3yKgnYdVV7Oh1YUxHeF-U4Z4FOwbX-n6aPU=.777415ac-9838-4abd-8160-009128de59be@github.com>

On Mon, 6 Jun 2022 20:19:22 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
>> - `languageTag` is read twice in `toLanguageTag()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287860: Rename local vars

Looks good. Thanks for fixing this.

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

Marked as reviewed by naoto (Reviewer).

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

From naoto at openjdk.java.net  Mon Jun  6 20:37:15 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 20:37:15 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
 [v2]
In-Reply-To: <KibQ69PG_ptQjnEavrpaTSMyg2wJ42lCpJcP_-dmLp8=.0b8f5990-bfe4-47a3-8919-5232bb2a613b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <KibQ69PG_ptQjnEavrpaTSMyg2wJ42lCpJcP_-dmLp8=.0b8f5990-bfe4-47a3-8919-5232bb2a613b@github.com>
Message-ID: <sj-KZHlLb0p9flbo28uNbAsBWTt9oQHSRglH9OKKNi0=.36bf5b9b-70f0-49cb-8b3b-310f8d96dd3c@github.com>

On Mon, 6 Jun 2022 14:36:03 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
>> - `defaultLocale` field is read multiple times in `initDefault()`
>> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
>> - `languageTag` is read twice in `toLanguageTag()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287860: Mark hash fields with @Stable

src/java.base/share/classes/java/util/Locale.java line 1084:

> 1082:         Properties props = GetPropertyAction.privilegedGetProperties();
> 1083: 
> 1084:         Locale defaultLocale = Locale.defaultLocale;

I'd use a different local variable name so that it won't clash with the field name. The same holds for other locations (`isoLanguages` and `languageTag`)

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

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

From duke at openjdk.java.net  Mon Jun  6 20:37:18 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 6 Jun 2022 20:37:18 GMT
Subject: <i18n dev> RFR: 8287860: Revise usage of volatile in j.u.Locale
 [v2]
In-Reply-To: <sj-KZHlLb0p9flbo28uNbAsBWTt9oQHSRglH9OKKNi0=.36bf5b9b-70f0-49cb-8b3b-310f8d96dd3c@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
 <KibQ69PG_ptQjnEavrpaTSMyg2wJ42lCpJcP_-dmLp8=.0b8f5990-bfe4-47a3-8919-5232bb2a613b@github.com>
 <sj-KZHlLb0p9flbo28uNbAsBWTt9oQHSRglH9OKKNi0=.36bf5b9b-70f0-49cb-8b3b-310f8d96dd3c@github.com>
Message-ID: <P_GiK8drzCndNgnzZWV33P0BreOas5dBEIdz-ZybPUY=.b283a39e-5651-4662-8130-d195ad9d177f@github.com>

On Mon, 6 Jun 2022 17:31:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287860: Mark hash fields with @Stable
>
> src/java.base/share/classes/java/util/Locale.java line 1084:
> 
>> 1082:         Properties props = GetPropertyAction.privilegedGetProperties();
>> 1083: 
>> 1084:         Locale defaultLocale = Locale.defaultLocale;
> 
> I'd use a different local variable name so that it won't clash with the field name. The same holds for other locations (`isoLanguages` and `languageTag`)

Done!

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

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

From ihse at openjdk.java.net  Tue Jun  7 10:23:54 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 7 Jun 2022 10:23:54 GMT
Subject: <i18n dev> RFR: 8287896: PropertiesTest.sh fail on msys2
Message-ID: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>

The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, since it does not properly detect this environment.

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

Commit messages:
 - 8287896: PropertiesTest.sh fail on msys2

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

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

From naoto at openjdk.java.net  Tue Jun  7 11:45:18 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 7 Jun 2022 11:45:18 GMT
Subject: <i18n dev> RFR: 8287896: PropertiesTest.sh fail on msys2
In-Reply-To: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>
References: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>
Message-ID: <UaWILe0ypr8n14MNs07MtVtCHhHYfq72fTKsCCKbysk=.01047403-a519-445a-a978-78386cabfb82@github.com>

On Tue, 7 Jun 2022 10:14:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, since it does not properly detect this environment.

Looks good. Thanks for the change.

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

Marked as reviewed by naoto (Reviewer).

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

From duke at openjdk.java.net  Tue Jun  7 11:50:22 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Jun 2022 11:50:22 GMT
Subject: <i18n dev> Integrated: 8287860: Revise usage of volatile in
 j.u.Locale
In-Reply-To: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
References: <OlwCBkqwWS5HgPSrftdUj5Y9VnX_dFKKki67BNEwFGE=.7560aa45-37bb-45bc-81be-8b419c5b158b@github.com>
Message-ID: <_IWq0ve7avn9TEdgpYq_plxYzJV3X2RtBAXDvmHsAHQ=.f0eba0e0-29e6-4deb-b6e3-5bb69d5d783d@github.com>

On Mon, 6 Jun 2022 12:58:39 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> - cached hash code of `Locale` and `Locale$LanguageRange` shouldn't be volatile, even in case of race in the worst case it is recalculated at most once per thread
> - `defaultLocale` field is read multiple times in `initDefault()`
> - `isoLanguages` is accessed multiple times in `getISOLanguages()`
> - `languageTag` is read twice in `toLanguageTag()`

This pull request has now been integrated.

Changeset: 4fe0ca9e
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4fe0ca9ec3b995eb113ac214219cae22f83333c9
Stats:     24 lines in 2 files changed: 5 ins; 0 del; 19 mod

8287860: Revise usage of volatile in j.u.Locale

Reviewed-by: naoto

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

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

From ihse at openjdk.java.net  Tue Jun  7 11:57:18 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 7 Jun 2022 11:57:18 GMT
Subject: <i18n dev> Integrated: 8287896: PropertiesTest.sh fail on msys2
In-Reply-To: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>
References: <TR7KFYYLRCBQ_Z0Dyly0fEi3H1u6n5zqsAYOIjGu35c=.7455e954-c3b3-4bfe-a662-c59ee282a7cb@github.com>
Message-ID: <yLk6BwfQRE8P4jSozNKLNKamxN8j57LWiUagyP14hew=.6aa1de83-65e7-4d64-8710-344761c0e0e9@github.com>

On Tue, 7 Jun 2022 10:14:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test `test/jdk/java/util/Currency/PropertiesTest.sh` fails on msys2, since it does not properly detect this environment.

This pull request has now been integrated.

Changeset: f1dd559e
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f1dd559e20342b892d0c1ed0314e5bba451bc5d3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8287896: PropertiesTest.sh fail on msys2

Reviewed-by: naoto

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

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

From duke at openjdk.java.net  Tue Jun  7 14:15:55 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 7 Jun 2022 14:15:55 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v7]
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <mhpnjoL_era4xeDDmX7VzNdmFlcVkg6QKVcQWfNgcPo=.c144beee-dc9e-4b08-9b82-eeaca5ff36df@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:

  8285838: Simplified Daylight period checks for test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/87832663..f855493a

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

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

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

From duke at openjdk.java.net  Tue Jun  7 14:15:56 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 7 Jun 2022 14:15:56 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v6]
In-Reply-To: <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
Message-ID: <TbTxwyRJSfC1Qofi9ljuBiQ7w7jTAx5uaufbqi6X4uo=.fbbf7714-ee16-4a19-9e94-82381fd485f8@github.com>

On Wed, 1 Jun 2022 13:32:36 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8285838: Cleanup of trailing whitespace
>  - 8285838: Corrected month comparison check for TZ DST

Appreciate the suggestion, I fixed up my test and simplified it as you said, and checked against a few spawned LocalDate(s) to verify the functionality is still good.

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

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

From duke at openjdk.java.net  Tue Jun  7 14:18:52 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Tue, 7 Jun 2022 14:18:52 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v6]
In-Reply-To: <TbTxwyRJSfC1Qofi9ljuBiQ7w7jTAx5uaufbqi6X4uo=.fbbf7714-ee16-4a19-9e94-82381fd485f8@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <vOUJfxygrtXFECBWN8v5jMOy5uu4AW6oFd1nS0L5EkE=.21cf9a0a-5696-4e97-87df-92112c4a7906@github.com>
 <TbTxwyRJSfC1Qofi9ljuBiQ7w7jTAx5uaufbqi6X4uo=.fbbf7714-ee16-4a19-9e94-82381fd485f8@github.com>
Message-ID: <C_mKUFXh_euKcPiIOSwazbkIcQ5wcXDDlopAKnPXZuE=.fe341e2c-b7c0-46cd-94f7-82232a2af1d8@github.com>

On Tue, 7 Jun 2022 14:11:57 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8285838: Cleanup of trailing whitespace
>>  - 8285838: Corrected month comparison check for TZ DST
>
> Appreciate the suggestion, I fixed up my test and simplified it as you said, and checked against a few spawned LocalDate(s) to verify the functionality is still good.

@Deigue Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information.

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

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

From jpai at openjdk.java.net  Wed Jun  8 15:27:32 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 8 Jun 2022 15:27:32 GMT
Subject: <i18n dev> RFR: 8287902: UnreadableRB case in
 MissingResourceCauseTest is not working reliably on Windows
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <2aA1kJkksqDxbNMlKZq3CjNQ10C2Xf1TO4IT8-y3pX0=.27ab6afd-2138-4434-81b4-8954d2f8ff4e@github.com>

On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. 

I had quick look at the CI setup we have access to. It appears that this test passes there successfully on Windows. Could it be something to do with Windows version being used?

test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java line 48:

> 46:     private static void callGetBundle(String baseName, Locale locale,
> 47:                                       Class<? extends Throwable> expectedCause) {
> 48:         if (baseName.equals("UnreadableRB") && System.getProperty("os.name").startsWith("Windows")) {

Hello @magicus, perhaps we could do this check in the `main` of this class (line 37) before calling the `callGetBundle` for the `UnreadableRB` base name? That way this method doesn't have to bother about which `baseName` is being passed.

I had a quick look at how other tests do the OS name checks and they use the `Platform.isWindows()` API which is part of the test library. I suspect you may not be able to use it here though since this `MissingResourceCauseTest` class gets launched manually through the `MissingResourceCauseTestRun`. So using `System.getProperty` I think is fine. Nit - perhaps we could match this check to do whatever `Platform.isWindows()` is doing (which seems to be checking that the os name starts with `win`, ignoring the case).

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

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

From duke at openjdk.java.net  Wed Jun  8 17:40:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:40:40 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v18]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <1xVR4-ZIHnyfeei_7RmrCV8g8aVvzI3aGgUHIP8fZx4=.d4206519-b280-4021-8fbd-a2f46180e8d1@github.com>

> as title.

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

 - remove null check for Capacitiable in WhiteBoxResizeTest
 - Rename type variable per CSR request; minor spec wording change.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/98bfb0e1..bacc9ca8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=16-17

  Stats: 19 lines in 3 files changed: 0 ins; 13 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

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

From duke at openjdk.java.net  Wed Jun  8 17:40:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:40:43 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v17]
In-Reply-To: <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>
Message-ID: <vl6R4iBqQ81oJiQqySRtRgivszdAVIbjkraflV3FgvA=.c18bd636-d10d-4acc-a273-f1aef8624f53@github.com>

On Wed, 1 Jun 2022 17:34:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 441:
> 
>> 439:         }
>> 440:     }
>> 441: 
> 
> This unifies the test cases between the Set and Map factories, which accomplishes the primary goal. Good.
> 
> The unification is achieved through classic object-oriented polymorphism, which works fine, though which is rather verbose. This could probably be reduced with some tinkering on the model, but it's probably reaching the point where additional tinkering on the model isn't worth it. I'm ok with sticking with this approach for now. Maybe we can clean it up later, or maybe not -- it's at least fairly straightforward.
> 
> One issue that contributes to the verbosity is the repeated null checking. The null checking enables the test code to proceed and end up with -1 as the capacity if there's a null in there somewhere. This will cause the assertion to fail. This is good in that it will call attention to itself (as opposed to silently passing or something). However, if the test cases are set up properly, they should never run into null. If the null checking weren't done, an unexpected null will throw NPE, which will be caught be the framework and reported as an error.
> 
> That seems perfectly fine to me, so I'd suggest simply removing the null checking. That would also reduce the bulkiness of infrastructure.

@stuart-marks done.

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

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

From naoto at openjdk.java.net  Wed Jun  8 17:47:37 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 8 Jun 2022 17:47:37 GMT
Subject: <i18n dev> RFR: 8287902: UnreadableRB case in
 MissingResourceCauseTest is not working reliably on Windows
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>

On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

Thanks for the investigation, Magnus. I believe it is a bug to include the Windows environment in refactoring the shell script to Java. Why it's been working? No idea. Could be `IOException` has been thrown not by `unreadable` but for some other reason?

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

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

From duke at openjdk.java.net  Wed Jun  8 17:49:38 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:49:38 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v19]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>

> as title.

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

  clean up Calendar

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/bacc9ca8..95d59b97

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=17-18

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

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

From duke at openjdk.java.net  Wed Jun  8 17:49:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:49:40 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v17]
In-Reply-To: <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>
Message-ID: <EahYlBb628e0d_B3qOx1YbXqBmU0s5LKut12Z0nM_Qk=.39bbbf60-b42c-40ef-af52-3984487e176c@github.com>

On Wed, 1 Jun 2022 18:26:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> src/java.base/share/classes/java/util/Calendar.java line 2648:
> 
>> 2646:             set.add("gregory");
>> 2647:             set.add("buddhist");
>> 2648:             set.add("japanese");
> 
> This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

@naotoj Yes it can. I did a further clean up to it, please have a look.

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

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

From smarks at openjdk.java.net  Wed Jun  8 20:16:33 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 8 Jun 2022 20:16:33 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v19]
In-Reply-To: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
Message-ID: <66QMts98pQNLZzxi4BlX-aj13JkeVQeB8v8MNKVrpDY=.9b8680cc-f54e-4d7f-9b25-806b367d835b@github.com>

On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up Calendar

Running tests and awaiting review from security team. Our internal test system is backlogged and tests might not complete in time to get into JDK 19.

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

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

From ascarpino at openjdk.java.net  Wed Jun  8 20:31:43 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 8 Jun 2022 20:31:43 GMT
Subject: <i18n dev> RFR: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet [v19]
In-Reply-To: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
Message-ID: <kqydNmdnzsVvm6ITkeY9avGcwLvwp9C4T8HeILLC12U=.6d177140-6176-44b5-9b4b-bd78570a078d@github.com>

On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up Calendar

I gave a quick look at the security files touched and seems straightforward. I didn't see any problems

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

Marked as reviewed by ascarpino (Reviewer).

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

From duke at openjdk.java.net  Thu Jun  9 01:54:37 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 9 Jun 2022 01:54:37 GMT
Subject: <i18n dev> Integrated: 8284780: Need methods to create pre-sized
 HashSet and LinkedHashSet
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <uBGmXlQd9TXwXKbiDcrVcLUktKK4rTenr6JRZx7MBjA=.9a961a01-5109-4e38-8594-c3413bdf0c8c@github.com>

On Tue, 19 Apr 2022 18:00:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> as title.

This pull request has now been integrated.

Changeset: e01cd7c3
Author:    XenoAmess <xenoamess at gmail.com>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e01cd7c3ed923cd19509fc972ba6e4aa2991289f
Stats:     154 lines in 29 files changed: 107 ins; 7 del; 40 mod

8284780: Need methods to create pre-sized HashSet and LinkedHashSet

Reviewed-by: naoto, bpb, dfuchs, ascarpino

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

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

From ihse at openjdk.java.net  Thu Jun  9 08:25:32 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Jun 2022 08:25:32 GMT
Subject: <i18n dev> RFR: 8287902: UnreadableRB case in
 MissingResourceCauseTest is not working reliably on Windows
In-Reply-To: <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
 <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>
Message-ID: <LofjxogQ2FqWanowgpQnSNNuY0gyt_D5JWWqjTtxI6k=.cbd713a9-e6dd-46cc-ad8c-fb8de193a751@github.com>

On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
>> 
>> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
>> 
>> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
>> 
>> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
>> 
>> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).
>
> Thanks for the investigation, Magnus. I believe it is a bug to include the Windows environment in refactoring the shell script to Java. Why it's been working? No idea. Could be `IOException` has been thrown not by `unreadable` but for some other reason?

@naotoj Yes, that could be a likely possibility. Perhaps the file were never created, or not in the expected place?

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

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

From naoto at openjdk.java.net  Thu Jun  9 15:45:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 9 Jun 2022 15:45:38 GMT
Subject: <i18n dev> RFR: 8287902: UnreadableRB case in
 MissingResourceCauseTest is not working reliably on Windows
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <Zkua61UFVk-eSqEZmXh_Q8OqaTTTgCKa6mizEHvBMr4=.f0dcb414-7c94-42e3-baed-f645f0a18529@github.com>

On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

Marked as reviewed by naoto (Reviewer).

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

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

From naoto at openjdk.java.net  Thu Jun  9 15:45:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 9 Jun 2022 15:45:41 GMT
Subject: <i18n dev> RFR: 8287902: UnreadableRB case in
 MissingResourceCauseTest is not working reliably on Windows
In-Reply-To: <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
 <l29ejUGywbsEOd8RcxlM53T_lq9EcfAZhEvTfkwgq8Y=.b002ece3-c994-4df1-8fcc-db6ee89b10ce@github.com>
Message-ID: <rewRsxMriFNAhUbo5rVPijDEoX1Cv76vRB3swWysF_U=.257bc9fa-1052-4d8e-a7d4-aeb94bcc92c4@github.com>

On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
>> 
>> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
>> 
>> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
>> 
>> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
>> 
>> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).
>
> Thanks for the investigation, Magnus. I believe it is a bug to include the Windows environment in refactoring the shell script to Java. Why it's been working? No idea. Could be `IOException` has been thrown not by `unreadable` but for some other reason?

> @naotoj Yes, that could be a likely possibility. Perhaps the file were never created, or not in the expected place?

I'd guess something like that too. Anyways, eliminating this unreliability in test is a good clean up. Approving the fix assuming Jai's comment is addressed.

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

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

From naoto at openjdk.java.net  Thu Jun  9 15:48:11 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 9 Jun 2022 15:48:11 GMT
Subject: <i18n dev> RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v7]
In-Reply-To: <mhpnjoL_era4xeDDmX7VzNdmFlcVkg6QKVcQWfNgcPo=.c144beee-dc9e-4b08-9b82-eeaca5ff36df@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <mhpnjoL_era4xeDDmX7VzNdmFlcVkg6QKVcQWfNgcPo=.c144beee-dc9e-4b08-9b82-eeaca5ff36df@github.com>
Message-ID: <8w3R129QhA-AkApB-3ngwJSrNcHtWum8ahjeT5BV6Jc=.e67e0c96-a49e-49ee-8a36-875a1e5e35ed@github.com>

On Tue, 7 Jun 2022 14:15:55 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285838: Simplified Daylight period checks for test.

Looks good. Thanks for the contribution.

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

Marked as reviewed by naoto (Reviewer).

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

From ihse at openjdk.java.net  Fri Jun 10 10:11:32 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 10:11:32 GMT
Subject: <i18n dev> Integrated: 8287902: UnreadableRB case in
 MissingResourceCauseTest is not working reliably on Windows
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <ZR2plvRXZA99gl1gb_syJkvyLcbzTvCK9Vx7GcRL138=.de1b8af2-e075-4fe0-8bde-b8424bba25ac@github.com>

On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

This pull request has now been integrated.

Changeset: 975316e3
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/975316e3e5f1208e4e15eadc2493d25c15554647
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows

Reviewed-by: naoto

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

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

From ihse at openjdk.java.net  Fri Jun 10 10:11:31 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 10 Jun 2022 10:11:31 GMT
Subject: <i18n dev> RFR: 8287902: UnreadableRB case in
 MissingResourceCauseTest is not working reliably on Windows [v2]
In-Reply-To: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
References: <LwyfaR5xQfxD1yEk-jaHiEYXvB-nU37zxJXJQhZXsIA=.c8a984bf-cee2-45ad-a66f-4461cec4d56e@github.com>
Message-ID: <raqP06TCF3UrNUDMMJC3hnXlmT8hjsUx2paN73feR8A=.baa01e97-4c53-4ab5-b56c-e69f7f00d862@github.com>

> The test  `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java` verifies different failure modes of resource bundles. One of the failures is that the runner class, `MissingResourceCauseTestRun.java`, creates a file `UnreadableRB`, and runs `chmod 000` on it, to make it unreadable by the test. Then MissingResourceCauseTest is called, and the `UnreadableRB` file is removed.
> 
> This does not work reliably on Windows. On msys2, `chmod` is essentially a no-op, so the file is not made unreadable, and hence the test fails. In my personal cygwin test environment, the chmod command does have some effect, but it is still not enough to make the file unreadable, and so the test fails.
> 
> The test was originally a shell script test that got converted to Java in [JDK-4354216](https://bugs.openjdk.org/browse/JDK-8213127). The original shell script code explicitly excluded Windows from testing. This was changed in the rewrite, for reasons I cannot determine.
> 
> What suprises me, though, is the "how can this ever has worked???" factor. Apparently the test passes on the current Cygwin setup on GHA. I have failed to reproduce the working conditions that makes a file actually unreadable for the owner on Windows, neither on my GHA test repo, nor locally. I've searched the web to figure out how to properly set file permissions on Windows to make the file unreadable, using Windows native tools, to no avail. I've even asked a [Stack Overflow question](https://stackoverflow.com/questions/72528318/what-file-permissions-make-a-file-unreadable-by-owner-in-windows); which as of yet is still unanswered.
> 
> Since I feel I've spent far more time than reasonable trying to get this to work properly, I suggest we instead skip the unreadable test on Windows. It is clearly unstable and highly depending on the Windows environment, the test was never originally supported or intended for Windows, and at the of the day, testing file unreadability is not an important regression test for [JDK-4354216](https://bugs.openjdk.org/browse/JDK-4354216).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  From code review:  use more robust OS check and move it to main()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9061/files
  - new: https://git.openjdk.org/jdk/pull/9061/files/7cd2dccf..162e928c

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

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

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

From naoto at openjdk.java.net  Fri Jun 10 21:05:42 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 10 Jun 2022 21:05:42 GMT
Subject: <i18n dev> RFR: 8287868: Localized names update in COMPAT locale
 provider
Message-ID: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>

As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.

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

Commit messages:
 - 8287868: Localized names update in COMPAT locale provider

Changes: https://git.openjdk.org/jdk/pull/9134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9134&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287868
  Stats: 9930 lines in 65 files changed: 17 ins; 7 del; 9906 mod
  Patch: https://git.openjdk.org/jdk/pull/9134.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9134/head:pull/9134

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

From ihse at openjdk.java.net  Sat Jun 11 09:58:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Sat, 11 Jun 2022 09:58:10 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
Message-ID: <H1W5bpGcXIH-8_JXu6cX9u2UEwHMfb52yJVB5rvfYVs=.a0302b8f-c2e1-43b4-ab5b-44e13c9f21b7@github.com>

On Fri, 13 May 2022 16:53:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
> 
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5

Thank you bot. I'm on it!

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

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

From naoto at openjdk.java.net  Tue Jun 14 01:03:15 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 14 Jun 2022 01:03:15 GMT
Subject: <i18n dev> RFR: 8288378: [BACKOUT] DST not applying properly with
 zone id offset set with TZ env variable
Message-ID: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>

Backing out a fix that is causing a T1 failure.

This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

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

Commit messages:
 - 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

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

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

From dholmes at openjdk.java.net  Tue Jun 14 01:04:59 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Jun 2022 01:04:59 GMT
Subject: <i18n dev> RFR: 8288378: [BACKOUT] DST not applying properly
 with zone id offset set with TZ env variable
In-Reply-To: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>
References: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>
Message-ID: <v5ecZPQbBCsJg_8GLCvkEuMVAqx8loQi-Rk_KbcwbLQ=.328c187f-ab04-4603-810d-b30640c7539c@github.com>

On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backing out a fix that is causing a T1 failure.
> 
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

Backout looks accurate - thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From naoto at openjdk.java.net  Tue Jun 14 01:10:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 14 Jun 2022 01:10:48 GMT
Subject: <i18n dev> Integrated: 8288378: [BACKOUT] DST not applying properly
 with zone id offset set with TZ env variable
In-Reply-To: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>
References: <9biLqn72iCYGyD9NFoqCjTsdXHB5Rx7CaCatvlxVQOA=.665d6e88-bd99-4b1b-91d2-b97d5d350d01@github.com>
Message-ID: <8Eu9vpMcA3EMoW440c9LHJqjwYTpSPSq7g7qYE9Hbo4=.28f83a78-a70e-48b6-9d72-6081a6958f62@github.com>

On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backing out a fix that is causing a T1 failure.
> 
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

This pull request has now been integrated.

Changeset: fbe92666
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbe926662287283c579fdb4ca8290670500cf5a5
Stats:     95 lines in 2 files changed: 1 ins; 91 del; 3 mod

8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

Reviewed-by: dholmes

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

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

From aturbanov at openjdk.java.net  Wed Jun 15 07:31:56 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 15 Jun 2022 07:31:56 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
Message-ID: <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>

On Fri, 13 May 2022 16:53:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
> 
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5

src/java.desktop/share/classes/javax/swing/JTree.java line 3320:

> 3318:                                    (parent, path.getPathComponent(counter));
> 3319:                 parent = path.getPathComponent(counter);
> 3320:                 if(indices[counter - 1] < 0)

let's add space after `if`

src/java.desktop/share/classes/javax/swing/JTree.java line 3335:

> 3333:      */
> 3334:     private TreePath getPathForIndexs(int[] indices) {
> 3335:         if(indices == null)

please add space after `if`

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

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

From aivanov at openjdk.java.net  Wed Jun 15 10:12:46 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 15 Jun 2022 10:12:46 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
 <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>
Message-ID: <sid_RqGy2RIBuCmDj16ulAx0yTijUAtGwkySwLqgrC4=.45e0fb64-9d3c-4b61-b28e-3e826705f05c@github.com>

On Wed, 15 Jun 2022 07:27:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
>> 
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5
>
> src/java.desktop/share/classes/javax/swing/JTree.java line 3320:
> 
>> 3318:                                    (parent, path.getPathComponent(counter));
>> 3319:                 parent = path.getPathComponent(counter);
>> 3320:                 if(indices[counter - 1] < 0)
> 
> let's add space after `if`

Better not: if you look at the code around it, there's no space between a keyword and the opening parenthesis. So the code looks consistent. Changing this `if` will make the code inconsistent.

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

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

From ihse at openjdk.java.net  Wed Jun 15 10:45:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 15 Jun 2022 10:45:52 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
 <L49ntFdH5g3YCosPSB16px9r0Mm3vuohTKBPgD03e_I=.7376119e-5c11-4c20-b2f3-cfc68ce89145@github.com>
Message-ID: <E83YFbh2P18w84gm2LQAy5umVsaFq-O11pRGOcRnnms=.29da439d-c489-4f10-ac2e-3635540783d0@github.com>

On Wed, 15 Jun 2022 07:27:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
>> 
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5
>
> src/java.desktop/share/classes/javax/swing/JTree.java line 3320:
> 
>> 3318:                                    (parent, path.getPathComponent(counter));
>> 3319:                 parent = path.getPathComponent(counter);
>> 3320:                 if(indices[counter - 1] < 0)
> 
> let's add space after `if`

@turbanoff I'll go with @aivanov-jdk's suggestion here. Also, this is a PR created by an automation tool. I'd really prefer not to do any manual intervention, if possible, and at the very least not spelling related.

> src/java.desktop/share/classes/javax/swing/JTree.java line 3335:
> 
>> 3333:      */
>> 3334:     private TreePath getPathForIndexs(int[] indices) {
>> 3335:         if(indices == null)
> 
> please add space after `if`

Same here. Space issues are not typos.

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

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

From aturbanov at openjdk.org  Mon Jun 20 07:59:08 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 20 Jun 2022 07:59:08 GMT
Subject: <i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get call
 in java.time
Message-ID: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>

Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.

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

Commit messages:
 - [PATCH] Avoid redundant ConcurrentHashMap.get call in java.time

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

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

From attila at openjdk.org  Mon Jun 20 09:51:56 2022
From: attila at openjdk.org (Attila Szegedi)
Date: Mon, 20 Jun 2022 09:51:56 GMT
Subject: <i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get
 call in java.time
In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
Message-ID: <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>

On Sat, 18 Jun 2022 10:43:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.

src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 319:

> 317:                 store = prev;
> 318:             }
> 319:         }

You could do better here and use `computeIfAbsent` with `createStore` as its lambda. You could even change the signature of `createStore` to take `Entry<TemporalField, Locale>` as its parameter and then you could have this method be:

    private Object findStore(TemporalField field, Locale locale) {
        return CACHE.computeIfAbsent(createEntry(field, locale), this::createStore);
    }

    ...

    private Object createStore(Entry<TemporalField, Locale> entry) {
        ...
    }

This applies to most other changes you made, the one in `ZoneOffset` is the only one that's slightly different because there you have adjustment of `ID_CACHE` too.

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

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

From duke at openjdk.org  Mon Jun 20 15:05:58 2022
From: duke at openjdk.org (liach)
Date: Mon, 20 Jun 2022 15:05:58 GMT
Subject: <i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get
 call in java.time
In-Reply-To: <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>
Message-ID: <T1aGUhg2oja-wwEfNWodY5NDQu-0b_u7RrWD-Pll1Oc=.01a4d5f4-9985-43da-a45e-d5fb8bc6e966@github.com>

On Mon, 20 Jun 2022 09:11:31 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.
>
> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 319:
> 
>> 317:                 store = prev;
>> 318:             }
>> 319:         }
> 
> You could do better here and use `computeIfAbsent` with `createStore` as its lambda. You could even change the signature of `createStore` to take `Entry<TemporalField, Locale>` as its parameter and then you could have this method be:
> 
>     private Object findStore(TemporalField field, Locale locale) {
>         return CACHE.computeIfAbsent(createEntry(field, locale), this::createStore);
>     }
> 
>     ...
> 
>     private Object createStore(Entry<TemporalField, Locale> entry) {
>         ...
>     }
> 
> This applies to most other changes you made, the one in `ZoneOffset` is the only one that's slightly different because there you have adjustment of `ID_CACHE` too.

This behaves slightly different from the old initialization; the concurrent hash map blocks when the mapping function is run, just in case if non-blocking instantiation is what we want. If that's not a problem, I would prefer szegedi's suggestion.

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

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

From attila at openjdk.org  Tue Jun 21 09:38:57 2022
From: attila at openjdk.org (Attila Szegedi)
Date: Tue, 21 Jun 2022 09:38:57 GMT
Subject: <i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get
 call in java.time
In-Reply-To: <T1aGUhg2oja-wwEfNWodY5NDQu-0b_u7RrWD-Pll1Oc=.01a4d5f4-9985-43da-a45e-d5fb8bc6e966@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>
 <T1aGUhg2oja-wwEfNWodY5NDQu-0b_u7RrWD-Pll1Oc=.01a4d5f4-9985-43da-a45e-d5fb8bc6e966@github.com>
Message-ID: <usL6uqhM57HR3cx4cFvhH-T7liNKZiuzDDTJMQIHT6c=.f69117f8-1a3e-44d8-9b7c-38f4b3bdcbed@github.com>

On Mon, 20 Jun 2022 15:01:55 GMT, liach <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/DateTimeTextProvider.java line 319:
>> 
>>> 317:                 store = prev;
>>> 318:             }
>>> 319:         }
>> 
>> You could do better here and use `computeIfAbsent` with `createStore` as its lambda. You could even change the signature of `createStore` to take `Entry<TemporalField, Locale>` as its parameter and then you could have this method be:
>> 
>>     private Object findStore(TemporalField field, Locale locale) {
>>         return CACHE.computeIfAbsent(createEntry(field, locale), this::createStore);
>>     }
>> 
>>     ...
>> 
>>     private Object createStore(Entry<TemporalField, Locale> entry) {
>>         ...
>>     }
>> 
>> This applies to most other changes you made, the one in `ZoneOffset` is the only one that's slightly different because there you have adjustment of `ID_CACHE` too.
>
> This behaves slightly different from the old initialization; the concurrent hash map blocks when the mapping function is run, just in case if non-blocking instantiation is what we want. If that's not a problem, I would prefer szegedi's suggestion.

@liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in general block while the mapping function runs. It can block _some_ concurrent updates, namely those that [hash to the same bin](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0f801fe6fd2fcc181121f9846f6869ca3a03e18a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java*L324__;Iw!!ACWV5N9M2RV99hQ!P8yoeMlnUvtHjkt7aASC3W7kORgt-CC1N4xL3_4BkfK5KkZEmK_YY4Tcz-rBdSQCce1bIAa1kfyoNVMycumg$ ) and it won't block concurrent reads. I'm not saying the concern you raised isn't valid, just wanted to clarify that the situation is not nearly as grave as overall blocking; after all it ain't a `Collections.synchronizedMap` :-)

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

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

From naoto.sato at oracle.com  Tue Jun 21 17:08:36 2022
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 21 Jun 2022 10:08:36 -0700
Subject: <i18n dev> RFR: 8287868: Localized names update in COMPAT
 locale provider
In-Reply-To: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
References: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
Message-ID: <5c03e559-64ae-685e-f9ca-ed1bf776e59f@oracle.com>

Ping.

Naoto

On 6/10/22 2:05 PM, Naoto Sato wrote:
> As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.
> 
> -------------
> 
> Commit messages:
>   - 8287868: Localized names update in COMPAT locale provider
> 
> Changes: https://git.openjdk.org/jdk/pull/9134/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9134&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8287868
>    Stats: 9930 lines in 65 files changed: 17 ins; 7 del; 9906 mod
>    Patch: https://git.openjdk.org/jdk/pull/9134.diff
>    Fetch: git fetch https://git.openjdk.org/jdk pull/9134/head:pull/9134
> 
> PR: https://git.openjdk.org/jdk/pull/9134

From duke at openjdk.org  Tue Jun 21 17:10:24 2022
From: duke at openjdk.org (liach)
Date: Tue, 21 Jun 2022 17:10:24 GMT
Subject: <i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get
 call in java.time
In-Reply-To: <usL6uqhM57HR3cx4cFvhH-T7liNKZiuzDDTJMQIHT6c=.f69117f8-1a3e-44d8-9b7c-38f4b3bdcbed@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <ETKWiXtyDl-XgESfoUC3mg8MEgPBrlUpk1Ui7tnqTXk=.acc46a34-86cc-4288-a5fe-fa609dd7f70a@github.com>
 <T1aGUhg2oja-wwEfNWodY5NDQu-0b_u7RrWD-Pll1Oc=.01a4d5f4-9985-43da-a45e-d5fb8bc6e966@github.com>
 <usL6uqhM57HR3cx4cFvhH-T7liNKZiuzDDTJMQIHT6c=.f69117f8-1a3e-44d8-9b7c-38f4b3bdcbed@github.com>
Message-ID: <Nm1e96mMDxzm49EJQw_BlSb7J2JV26p51OYm9X_HfdI=.ed235894-4b38-42ab-a539-8efb00a8b225@github.com>

On Tue, 21 Jun 2022 09:35:34 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> This behaves slightly different from the old initialization; the concurrent hash map blocks when the mapping function is run, just in case if non-blocking instantiation is what we want. If that's not a problem, I would prefer szegedi's suggestion.
>
> @liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in general block while the mapping function runs. It can block _some_ concurrent updates, namely those that [hash to the same bin](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0f801fe6fd2fcc181121f9846f6869ca3a03e18a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java*L324__;Iw!!ACWV5N9M2RV99hQ!M4ZprjzcHmsRVcqNAOpWURcdiarGLRrv7X38D3a9Htm65FjMP7qzt8n8xS2ZS7FmPHKJ7qflZ0cOiqsTGQ$ ) and it won't block concurrent reads. I'm not saying the concern you raised isn't valid, just wanted to clarify that the situation is not nearly as grave as overall blocking; after all it ain't a `Collections.synchronizedMap` :-)

Yeah, since `putIfAbsent` may block `get` calls, the blocking of `computeIfAbsent` is minuscule as long as the creation code is efficient enough. Just be careful that when writing the lambda for `computeIfAbsent`, preferably write static lambdas (that doesn't use `this`, instances, or local variables) so that one lambda can be reused over time than having to create a new one on each invocation.

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

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

From iris at openjdk.org  Tue Jun 21 17:19:20 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 21 Jun 2022 17:19:20 GMT
Subject: <i18n dev> RFR: 8287868: Localized names update in COMPAT
 locale provider [v3]
In-Reply-To: <7TE5wWtqEEuIZFEM5-RgfVgrsH9spoCAZuXt2L0ZC6w=.e8219429-d3b0-4d72-b072-e494c62c874e@github.com>
References: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
 <7TE5wWtqEEuIZFEM5-RgfVgrsH9spoCAZuXt2L0ZC6w=.e8219429-d3b0-4d72-b072-e494c62c874e@github.com>
Message-ID: <vU85iHRs-gaxU7ETSyZr8MGdBzUwBAoolCge32FbDJM=.88d3494f-bce8-4a8c-ba02-851f816bfbf5@github.com>

On Mon, 13 Jun 2022 22:58:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed some failing tests

Marked as reviewed by iris (Reviewer).

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

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

From joehw at openjdk.org  Tue Jun 21 18:05:43 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 21 Jun 2022 18:05:43 GMT
Subject: <i18n dev> RFR: 8287868: Localized names update in COMPAT
 locale provider [v3]
In-Reply-To: <7TE5wWtqEEuIZFEM5-RgfVgrsH9spoCAZuXt2L0ZC6w=.e8219429-d3b0-4d72-b072-e494c62c874e@github.com>
References: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
 <7TE5wWtqEEuIZFEM5-RgfVgrsH9spoCAZuXt2L0ZC6w=.e8219429-d3b0-4d72-b072-e494c62c874e@github.com>
Message-ID: <tYEvFpoOHBUw9exX-fzthsXAdio6kRIyx3Mai_RkP6Q=.2e550611-2509-45e2-9027-04d075fd80a3@github.com>

On Mon, 13 Jun 2022 22:58:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed some failing tests

Marked as reviewed by joehw (Reviewer).

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

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

From djelinski at openjdk.org  Wed Jun 22 14:41:07 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 14:41:07 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time
Message-ID: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>

This PR improves the performance of deduplication done by ResourceBundleGenerator.

The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.

The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
The files generated before and after this change have the same size.

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

Commit messages:
 - Speed up CLDR deduplication

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

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

From naoto at openjdk.org  Wed Jun 22 15:50:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 15:50:54 GMT
Subject: <i18n dev> Integrated: 8287868: Localized names update in COMPAT
 locale provider
In-Reply-To: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
References: <7fDRDdqHEFf7mcTbsejR9dcX18v5mlbdzje5SwTpxgo=.fe37eff7-51c8-466c-a898-7756193d73f4@github.com>
Message-ID: <kKnNw9qsPBoOZn3UhNLU6cWyv1mfDiGiixbgMntwjgE=.8a240bb3-a098-47c9-a32b-ebd16c958cbb@github.com>

On Fri, 10 Jun 2022 20:58:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's locale data (before CLDR).  This is useful for legacy applications, but some of its data got obsolete for later locale data updates, such as the country name change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those names up-to-date from CLDR. More specifically, changes are made for `language`, `country`, `script` display names in `Locale` class, and `Currency` display names. Localized names used for `TimeZone`s and `Currency` symbols (such as `$`) are not modified so that `format`/`parse` should work as with JDK8.

This pull request has now been integrated.

Changeset: d4de4757
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4de4757471d9f21c2a059f91504ecbc4781566e
Stats:     11617 lines in 65 files changed: 17 ins; 2367 del; 9233 mod

8287868: Localized names update in COMPAT locale provider

Reviewed-by: iris, joehw

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

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

From rriggs at openjdk.org  Wed Jun 22 16:22:15 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Jun 2022 16:22:15 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>

On Wed, 22 Jun 2022 14:24:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:

> 144:             // generic reduction of duplicated values
> 145:             Map<String, Object> newMap = new HashMap<>(map);
> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());

LinkedHashMap could be used to retain the iteration order.
Or TreeMap if some deterministic order was desirable.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 157:

> 155:                             fmt = new Formatter();
> 156:                         }
> 157:                         String metaVal = oldEntry.metaKey();

The new instanceof pattern matching could be used avoid the cast below.

make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 270:

> 268:                 if (value instanceof String s) {
> 269:                     return s.equals(entry.value);
> 270:                 } else if (!(entry.value instanceof String[])) {

Could be re-written to use instanceof pattern and save a cast.

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

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

From djelinski at openjdk.org  Wed Jun 22 17:10:55 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 17:10:55 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time
In-Reply-To: <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
Message-ID: <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>

On Wed, 22 Jun 2022 16:11:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:
> 
>> 144:             // generic reduction of duplicated values
>> 145:             Map<String, Object> newMap = new HashMap<>(map);
>> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());
> 
> LinkedHashMap could be used to retain the iteration order.
> Or TreeMap if some deterministic order was desirable.

True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.

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

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

From djelinski at openjdk.org  Wed Jun 22 17:30:48 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 22 Jun 2022 17:30:48 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Use instanceof pattern matching

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9243/files
  - new: https://git.openjdk.org/jdk/pull/9243/files/c3743d18..6cb47724

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

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

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

From rriggs at openjdk.org  Wed Jun 22 17:30:51 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 22 Jun 2022 17:30:51 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
Message-ID: <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>

On Wed, 22 Jun 2022 17:07:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java line 146:
>> 
>>> 144:             // generic reduction of duplicated values
>>> 145:             Map<String, Object> newMap = new HashMap<>(map);
>>> 146:             Map<BundleEntryValue, BundleEntryValue> dedup = new HashMap<>(map.size());
>> 
>> LinkedHashMap could be used to retain the iteration order.
>> Or TreeMap if some deterministic order was desirable.
>
> True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.

A stable order is useful when comparing between builds (by a human). 
It also supports the goal of reproducible builds.
@naotoj  What do you think?

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

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

From naoto at openjdk.org  Wed Jun 22 18:02:07 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 18:02:07 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
Message-ID: <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>

On Wed, 22 Jun 2022 17:27:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> True. Which raises the question: do we need any arbitrary order? The original code used a hashmap too. It preserved the original order only when no duplicates were detected.
>
> A stable order is useful when comparing between builds (by a human). 
> It also supports the goal of reproducible builds.
> @naotoj  What do you think?

IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?

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

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

From aturbanov at openjdk.org  Wed Jun 22 21:29:50 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 Jun 2022 21:29:50 GMT
Subject: <i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get
 call in java.time [v2]
In-Reply-To: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
Message-ID: <YvqHz0tTpqqN-X0evw3C0GdubG6m435J_gvFpVkCZvM=.11697c65-a20e-428d-bc8e-e56d01848b52@github.com>

> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8288723: Avoid redundant ConcurrentHashMap.get call in java.time
  use computeIfAbsent where lambda could be short and static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9208/files
  - new: https://git.openjdk.org/jdk/pull/9208/files/73a2f6cb..aa67cdf6

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

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

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

From naoto at openjdk.org  Wed Jun 22 21:51:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 21:51:42 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <GNbRMZG2qKz5mTOajQDN5D2irerbicTPIuDUch-sh0Y=.f2543f76-a773-4219-8268-e43b2c0452a8@github.com>
Message-ID: <3wfGl3xjVGdG52MQJnW48OogCIctlTpQkySX_oKx95c=.8ddb037c-a37b-4284-9e0d-dea038b2fc10@github.com>

On Wed, 22 Jun 2022 17:30:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use instanceof pattern matching

Thanks for the refactoring Daniel. Removing the leftover `List` was a bonus.

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

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

From naoto at openjdk.org  Wed Jun 22 21:51:42 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 22 Jun 2022 21:51:42 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v2]
In-Reply-To: <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
Message-ID: <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>

On Wed, 22 Jun 2022 17:57:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A stable order is useful when comparing between builds (by a human). 
>> It also supports the goal of reproducible builds.
>> @naotoj  What do you think?
>
> IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?

BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

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

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

From djelinski at openjdk.org  Thu Jun 23 08:53:37 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 08:53:37 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Sort output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9243/files
  - new: https://git.openjdk.org/jdk/pull/9243/files/6cb47724..8d26e537

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

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

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

From djelinski at openjdk.org  Thu Jun 23 08:59:41 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 08:59:41 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
 <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
Message-ID: <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>

On Wed, 22 Jun 2022 21:45:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> IIUC, once this fix makes it to the repository, the build will be reproducible. Making it to be sorted is a welcome enhancement (I compare the generated bundles manually from time to time), but it may be costly so it could defy the performance improvement?
>
> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

> once this fix makes it to the repository, the build will be reproducible

Yes, we always produce the same source code. Given the same order of modifications, a hashmap will produce the same iteration order.

> LinkedHashMap could be used to retain the iteration order.

Just added. The input maps were always sorted in some order (they were either LinkedHashMaps or TreeMaps), and now we preserve that order.
This means a lot of changes in the generated output files now, but hopefully in the future the changes will be much easier to review.

TIL: `put` / `putIfAbsent` on an existing entry does not change the iteration order of a `LinkedHashMap` unless `accessOrder` is true.

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

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

From djelinski at openjdk.org  Thu Jun 23 09:04:41 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 09:04:41 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <wz124fKQn2-5D4UClkQio8OWjodF7UPigEXztfANbI0=.60573b34-dd4a-4764-a243-005859bac43a@github.com>
 <8GdQ3xogOEjYUEYyOu1ryPXvYL9hiqxSBQ_vQmqyRE0=.ed513d11-9b3c-4256-8d59-3be410f6735c@github.com>
 <aIfWDx0KtZvFhOf8Jw_NeMtlkZ6WtWlxJKeNoIaKNxI=.450d721b-48d5-4dc3-b4b6-fa4b86d0de6c@github.com>
 <VgTYYO5SaGu-KSu5HuM8oILkBReE0isNi3GVP3HvhaU=.6ad95bbf-ac98-4983-b09a-acdbee20beab@github.com>
 <1lhu9rBdV8kgUcXp7M366TsqQn6ZTycWd7UsgEnVopM=.b04c2c39-8482-492f-af0a-bff7a28ba428@github.com>
 <Q4tqgNMy885ng7J5zMyZTySXn2Vl3DXVFhAJ14svPck=.68d2eae1-2d6b-4a71-9a12-24db60253304@github.com>
Message-ID: <Sxyc5_9-pgmZWN-TjJ5MAcplaRfbFxDE8LKw6_7-Ors=.89d59d50-909e-4022-beac-b3fd517495c0@github.com>

On Thu, 23 Jun 2022 08:56:08 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.
>
>> once this fix makes it to the repository, the build will be reproducible
> 
> Yes, we always produce the same source code. Given the same order of modifications, a hashmap will produce the same iteration order.
> 
>> LinkedHashMap could be used to retain the iteration order.
> 
> Just added. The input maps were always sorted in some order (they were either LinkedHashMaps or TreeMaps), and now we preserve that order.
> This means a lot of changes in the generated output files now, but hopefully in the future the changes will be much easier to review.
> 
> TIL: `put` / `putIfAbsent` on an existing entry does not change the iteration order of a `LinkedHashMap` unless `accessOrder` is true.

> BTW, this can utilize the new `HashMap.newHashMap()`, although I don't think resizing would be occurring in this case.

It may occur if there are very few duplicates. Still, the performance impact of proper sizing is minimal here.

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

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

From rriggs at openjdk.org  Thu Jun 23 14:12:45 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jun 2022 14:12:45 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
Message-ID: <d3675Rh7ela5uoRkzdhFeolJTba62VmXd5YzRdHI8iU=.a7141101-6612-4def-a203-81a409f7968e@github.com>

On Thu, 23 Jun 2022 08:53:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort output

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From naoto at openjdk.org  Thu Jun 23 18:10:03 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 18:10:03 GMT
Subject: <i18n dev> RFR: 8288979: Improve CLDRConverter run time [v3]
In-Reply-To: <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
 <0X50hfiZvQw-sJ8MWg7cjv-NZYo888__IIODZOGei5w=.34de9317-50c9-4dd2-a60d-9fd44fbf4c68@github.com>
Message-ID: <LMsVhWm07B08Ez1wuH5CO7PkHmmZ8U5GxYGakB4tuVA=.a3e42979-71d8-4159-acc2-229b6c173e4c@github.com>

On Thu, 23 Jun 2022 08:53:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This PR improves the performance of deduplication done by ResourceBundleGenerator.
>> 
>> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
>> 
>> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
>> The files generated before and after this change have the same size.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Sort output

Marked as reviewed by naoto (Reviewer).

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

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

From djelinski at openjdk.org  Thu Jun 23 18:49:37 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 23 Jun 2022 18:49:37 GMT
Subject: <i18n dev> Integrated: 8288979: Improve CLDRConverter run time
In-Reply-To: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
References: <vpLS2JnBzdya0HubC101TJdc-51-tRjrgj6QQkMog4k=.7d980cd1-f0f4-4aaa-8a2e-497231584ea0@github.com>
Message-ID: <WnG_9rwqqvOULJk3UsgLKos5VRGF7GBxFMx54yxuqK8=.84b5fb49-b93e-484b-9ae7-3bddb2a5b823@github.com>

On Wed, 22 Jun 2022 14:24:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR improves the performance of deduplication done by ResourceBundleGenerator.
> 
> The original implementation compared every pair of values, requiring O(n^2) time. The new implementation uses a HashMap to find duplicates, trading off some extra memory consumption for O(n) computational complexity. In practice the time to generate jdk.localedata on my Linux VM files dropped from 14 to 8 seconds.
> 
> The resulting files (under build/support/gensrc/java.base and jdk.localedata) have different contents; map iteration order depends on the insertion order, and the insertion order of the new implementation is different from the original.
> The files generated before and after this change have the same size.

This pull request has now been integrated.

Changeset: c8cc94a3
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8cc94a38423c0cef597986fb51938a26dc20b51
Stats:     100 lines in 1 file changed: 55 ins; 27 del; 18 mod

8288979: Improve CLDRConverter run time

Reviewed-by: naoto, rriggs

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

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

From aturbanov at openjdk.org  Thu Jun 23 19:44:56 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 23 Jun 2022 19:44:56 GMT
Subject: <i18n dev> RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>
Message-ID: <PPSTUbLpJnkQgZUlXyikcp9Vjq1D0J8ly5qZQfxJBX4=.51002137-8a00-4dfe-af6b-c5c152be0d1c@github.com>

On Fri, 13 May 2022 16:53:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
>> 
>> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
> 
>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/40c585cd...98e635a5

Marked as reviewed by aturbanov (Committer).

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

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

From jpai at openjdk.org  Fri Jun 24 07:25:38 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 24 Jun 2022 07:25:38 GMT
Subject: <i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get
 call in java.time [v2]
In-Reply-To: <YvqHz0tTpqqN-X0evw3C0GdubG6m435J_gvFpVkCZvM=.11697c65-a20e-428d-bc8e-e56d01848b52@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <YvqHz0tTpqqN-X0evw3C0GdubG6m435J_gvFpVkCZvM=.11697c65-a20e-428d-bc8e-e56d01848b52@github.com>
Message-ID: <OoSH2yLNim7NygIHCkn8uasHe92t8v6UqhlH8obgavM=.0011a3ac-a881-4721-b938-073d7ad0c8a1@github.com>

On Wed, 22 Jun 2022 21:29:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Instead of separate ConcurrentHashMap.get call, we can use result of previous putIfAbsent call.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288723: Avoid redundant ConcurrentHashMap.get call in java.time
>   use computeIfAbsent where lambda could be short and static

src/java.base/share/classes/java/time/temporal/WeekFields.java line 331:

> 329:         String key = firstDayOfWeek.toString() + minimalDaysInFirstWeek;
> 330:         WeekFields rules = CACHE.get(key);
> 331:         if (rules == null) {

Perhaps you don't even need this `if` block and the preceding `CACHE.get(key)` and maybe it can be replaced with:


return CACHE.computeIfAbsent(key, ignore -> new WeekFields(firstDayOfWeek, minimalDaysInFirstWeek));

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

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

From aturbanov at openjdk.org  Tue Jun 28 07:30:42 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Jun 2022 07:30:42 GMT
Subject: <i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get
 call in java.time [v2]
In-Reply-To: <OoSH2yLNim7NygIHCkn8uasHe92t8v6UqhlH8obgavM=.0011a3ac-a881-4721-b938-073d7ad0c8a1@github.com>
References: <1bekbwAy6dpPTkrR8UPh6y-SMuc6byKc63DARRylNhE=.f4cf6cc6-370b-4b76-9b38-a580abc5da5b@github.com>
 <YvqHz0tTpqqN-X0evw3C0GdubG6m435J_gvFpVkCZvM=.11697c65-a20e-428d-bc8e-e56d01848b52@github.com>
 <OoSH2yLNim7NygIHCkn8uasHe92t8v6UqhlH8obgavM=.0011a3ac-a881-4721-b938-073d7ad0c8a1@github.com>
Message-ID: <IKtphady07STgw-sX9HTmaT3_noNWFeq4pL4U5LE2nc=.cd595c0e-5a1f-42b1-902c-fd7886a2e579@github.com>

On Fri, 24 Jun 2022 07:22:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8288723: Avoid redundant ConcurrentHashMap.get call in java.time
>>   use computeIfAbsent where lambda could be short and static
>
> src/java.base/share/classes/java/time/temporal/WeekFields.java line 331:
> 
>> 329:         String key = firstDayOfWeek.toString() + minimalDaysInFirstWeek;
>> 330:         WeekFields rules = CACHE.get(key);
>> 331:         if (rules == null) {
> 
> Perhaps you don't even need this `if` block and the preceding `CACHE.get(key)` and maybe it can be replaced with:
> 
> 
> return CACHE.computeIfAbsent(key, ignore -> new WeekFields(firstDayOfWeek, minimalDaysInFirstWeek));

But it will generate garbage: non-static lambda.

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

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

From naoto at openjdk.org  Tue Jun 28 17:21:12 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Jun 2022 17:21:12 GMT
Subject: <i18n dev> [jdk19] RFR: 8289252: Recommend Locale.of() method
 instead of the constructor
Message-ID: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>

This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

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

Commit messages:
 - 8289252: Recommend Locale.of() method instead of the constructor

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

PR: https://git.openjdk.org/jdk19/pull/85

From duke at openjdk.org  Tue Jun 28 19:01:14 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Tue, 28 Jun 2022 19:01:14 GMT
Subject: <i18n dev> RFR: 8288377: [REDO] DST not applying properly with zone
 id offset set with TZ env variable
Message-ID: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>

This is a REDO of the Fix that was incompletely implemented earlier:
[8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)

Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.

I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
_(where 7200 represents 7200 seconds -> +2 hour offset)_
Sample output:
![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

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

Commit messages:
 - 8288377: Offset calculation fix for DST with custom TZ.

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

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

From joehw at openjdk.org  Tue Jun 28 19:13:50 2022
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 28 Jun 2022 19:13:50 GMT
Subject: <i18n dev> [jdk19] RFR: 8289252: Recommend Locale.of() method
 instead of the constructor
In-Reply-To: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
Message-ID: <r_zDjjfVpUhfb2WDhdBwvWLOvyP2yaVlRmfg5ZbOKPQ=.6a43a09d-0767-48d2-b9d2-7d0fb0cfc3db@github.com>

On Tue, 28 Jun 2022 17:11:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/85

From rriggs at openjdk.org  Tue Jun 28 19:48:43 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Jun 2022 19:48:43 GMT
Subject: <i18n dev> [jdk19] RFR: 8289252: Recommend Locale.of() method
 instead of the constructor
In-Reply-To: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
Message-ID: <8t72emKs6l_1R62QGTZTLFVMwfUAyClhiEl-Yr7doSo=.6a2c9581-4b48-4dcc-9c32-b1cb400cc707@github.com>

On Tue, 28 Jun 2022 17:11:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

src/java.base/share/classes/java/util/Locale.java line 2608:

> 2606:      * <p>The following example shows how to obtain a {@code Locale} object
> 2607:      * using a {@code Builder}.
> 2608:      * {@snippet :

Style-wise, adding the language of the snippet would be a plus:

`@snippet lang=java :`

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

PR: https://git.openjdk.org/jdk19/pull/85

From naoto at openjdk.org  Tue Jun 28 20:17:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Jun 2022 20:17:22 GMT
Subject: <i18n dev> [jdk19] RFR: 8289252: Recommend Locale.of() method
 instead of the constructor [v2]
In-Reply-To: <8t72emKs6l_1R62QGTZTLFVMwfUAyClhiEl-Yr7doSo=.6a2c9581-4b48-4dcc-9c32-b1cb400cc707@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
 <8t72emKs6l_1R62QGTZTLFVMwfUAyClhiEl-Yr7doSo=.6a2c9581-4b48-4dcc-9c32-b1cb400cc707@github.com>
Message-ID: <ezNDtr4cTp0pqwfSwZyzVic00oipqrwVjESpfUvpVu0=.71e1eecb-5de0-4f7b-8654-4133da045836@github.com>

On Tue, 28 Jun 2022 19:45:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added `lang` attribute to the snippet
>
> src/java.base/share/classes/java/util/Locale.java line 2608:
> 
>> 2606:      * <p>The following example shows how to obtain a {@code Locale} object
>> 2607:      * using a {@code Builder}.
>> 2608:      * {@snippet :
> 
> Style-wise, adding the language of the snippet would be a plus:
> 
> `@snippet lang=java :`

Good point. Added.

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

PR: https://git.openjdk.org/jdk19/pull/85

From naoto at openjdk.org  Tue Jun 28 20:17:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Jun 2022 20:17:21 GMT
Subject: <i18n dev> [jdk19] RFR: 8289252: Recommend Locale.of() method
 instead of the constructor [v2]
In-Reply-To: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
Message-ID: <NmAfQ1ybOR4KQYteNZtCLgaCZp0AkWh_Br6MGIAnY-8=.cb7b2333-73ca-4d23-a0e7-79740f78fa96@github.com>

> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

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

  added `lang` attribute to the snippet

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/85/files
  - new: https://git.openjdk.org/jdk19/pull/85/files/258aff4e..ce39f751

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

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

PR: https://git.openjdk.org/jdk19/pull/85

From rriggs at openjdk.org  Tue Jun 28 20:29:53 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 28 Jun 2022 20:29:53 GMT
Subject: <i18n dev> [jdk19] RFR: 8289252: Recommend Locale.of() method
 instead of the constructor [v2]
In-Reply-To: <NmAfQ1ybOR4KQYteNZtCLgaCZp0AkWh_Br6MGIAnY-8=.cb7b2333-73ca-4d23-a0e7-79740f78fa96@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
 <NmAfQ1ybOR4KQYteNZtCLgaCZp0AkWh_Br6MGIAnY-8=.cb7b2333-73ca-4d23-a0e7-79740f78fa96@github.com>
Message-ID: <mtRkeJw0BALR65696Skb7kL-g0-mgYD-YwX-GZPRuOg=.232b197c-5a21-4f57-b35b-087f003fb0a4@github.com>

On Tue, 28 Jun 2022 20:17:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added `lang` attribute to the snippet

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/85

From naoto at openjdk.org  Tue Jun 28 22:19:31 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Jun 2022 22:19:31 GMT
Subject: <i18n dev> RFR: 8288377: [REDO] DST not applying properly with
 zone id offset set with TZ env variable
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <pLyfFSkudoD_Mcy2Tnac0Vrteafqhghp8KO5rPhycd8=.a681a16c-8a72-4a15-b292-490e98e3f12d@github.com>

On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

I just wonder we could simply call `strftime` with `%z` conversion, rather than calculating the GMT offset ourselves. Would you like to try it out?

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

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

From duke at openjdk.org  Wed Jun 29 14:38:45 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Wed, 29 Jun 2022 14:38:45 GMT
Subject: <i18n dev> RFR: 8288377: [REDO] DST not applying properly with
 zone id offset set with TZ env variable
In-Reply-To: <pLyfFSkudoD_Mcy2Tnac0Vrteafqhghp8KO5rPhycd8=.a681a16c-8a72-4a15-b292-490e98e3f12d@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
 <pLyfFSkudoD_Mcy2Tnac0Vrteafqhghp8KO5rPhycd8=.a681a16c-8a72-4a15-b292-490e98e3f12d@github.com>
Message-ID: <GzJE-76Yq4vmpqmkLOG9jR8epmrgmrzBPjBt_vO09bs=.226101a5-4f0c-4ab4-8c69-6de5ffcd87bf@github.com>

On Tue, 28 Jun 2022 22:15:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a REDO of the Fix that was incompletely implemented earlier:
>> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
>> 
>> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
>> 
>> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
>> _(where 7200 represents 7200 seconds -> +2 hour offset)_
>> Sample output:
>> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)
>
> I just wonder we could simply call `strftime` with `%z` conversion, rather than calculating the GMT offset ourselves. Would you like to try it out?

@naotoj Thanks for letting me know, hadn't tried that function yet. At first look it seems to working exactly as needed, but I will need to parse the result into substrings to put a semi-colon between the hour and minute offset, in order to match the output required. But definitely looks much simpler in comparison ...

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

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

From naoto at openjdk.org  Wed Jun 29 15:51:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Jun 2022 15:51:48 GMT
Subject: <i18n dev> [jdk19] Integrated: 8289252: Recommend Locale.of()
 method instead of the constructor
In-Reply-To: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
References: <rHZo2G_cSUtMNfMVRA4M2wqifj7lzKjm0SEXAteLqmk=.c3a1acec-8386-46b6-87d7-5e21a756e819@github.com>
Message-ID: <hehC3ivvST5ilsD0K28vL7Rh7amTc2sROVQiSNiM30M=.eadda121-9dd5-452b-83f4-c2fa7dc9c686@github.com>

On Tue, 28 Jun 2022 17:11:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a leftover documentation fix to the deprecation of `Locale` constructors. `Locale.Builder` class had some texts that suggested using one of those constructors, which need to be replaced with a `Locale.of()` method. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: cf715449
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/cf7154498fffba202b74b41a074f25c657b2e591
Stats:     14 lines in 1 file changed: 4 ins; 2 del; 8 mod

8289252: Recommend Locale.of() method instead of the constructor

Reviewed-by: joehw, rriggs

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

PR: https://git.openjdk.org/jdk19/pull/85

From naoto at openjdk.org  Wed Jun 29 15:57:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Jun 2022 15:57:40 GMT
Subject: <i18n dev> RFR: 8288377: [REDO] DST not applying properly with
 zone id offset set with TZ env variable
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <4OE16SpqusTjcAqccMuhmDhyFNCM0P_gMX4FCY92VEI=.3e13d96e-53d1-498d-b6d1-81aa532e2303@github.com>

On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

I think you could simplify the code further, i.e. there will be no need to separate the function with `#if defined(MACOSX)`. The code can be shared with all Unix platforms.

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

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

From jwilhelm at openjdk.org  Wed Jun 29 23:29:28 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 29 Jun 2022 23:29:28 GMT
Subject: <i18n dev> RFR: Merge jdk19
Message-ID: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289252: Recommend Locale.of() method instead of the constructor
 - 8288596: Random:from() adapter does not delegate to supplied generator in all cases
 - 8289399: Update SourceVersion to use snippets

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9330&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9330&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9330/files
  Stats: 116 lines in 4 files changed: 102 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9330.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9330/head:pull/9330

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

From jwilhelm at openjdk.org  Wed Jun 29 23:37:38 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 29 Jun 2022 23:37:38 GMT
Subject: <i18n dev> Integrated: Merge jdk19
In-Reply-To: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>
References: <qbz6O1eYKsoroZdGs8jNszLJV6UryTXlA0o_O_83o5M=.855e3031-b34e-412e-ac2a-a17daad15323@github.com>
Message-ID: <jxYKBVWkUN-a9BQuUJqxJJ3EWvqH5H3uOHBCFBkLe5w=.e801259a-1af5-4c80-a6cc-4e3a53379d53@github.com>

On Wed, 29 Jun 2022 19:38:59 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 048bffad
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/048bffad79b302890059ffc1bc559bfc601de92c
Stats:     116 lines in 4 files changed: 102 ins; 2 del; 12 mod

Merge

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

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

From duke at openjdk.org  Thu Jun 30 18:32:56 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Thu, 30 Jun 2022 18:32:56 GMT
Subject: <i18n dev> RFR: 8288377: [REDO] DST not applying properly with
 zone id offset set with TZ env variable [v2]
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <C_c-ceEEIWA2iC__QiKGiYQhiIbeJU1Nr-uFC6UcEFA=.eff78830-d60c-43d6-a07b-263a115adb17@github.com>

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:

  8288377: Simplified TZ offset calc and consolidate MACOS impl.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9312/files
  - new: https://git.openjdk.org/jdk/pull/9312/files/f9230150..7e462d95

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

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

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

From duke at openjdk.org  Thu Jun 30 18:32:57 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Thu, 30 Jun 2022 18:32:57 GMT
Subject: <i18n dev> RFR: 8288377: [REDO] DST not applying properly with
 zone id offset set with TZ env variable
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <GjL6c_nM43XFR-uz23WrJnAfPlyjbBjGR8YHL_mk--k=.b7c8c836-6e58-4314-8135-c9eeb412f941@github.com>

On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

I have simplified the implementation and tested that it works on Linux ... I still need to check this on a MAC OS computer and see if it working like before without any issues.

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

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

From naoto at openjdk.org  Thu Jun 30 20:10:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 20:10:44 GMT
Subject: <i18n dev> RFR: 8288377: [REDO] DST not applying properly with
 zone id offset set with TZ env variable [v2]
In-Reply-To: <C_c-ceEEIWA2iC__QiKGiYQhiIbeJU1Nr-uFC6UcEFA=.eff78830-d60c-43d6-a07b-263a115adb17@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
 <C_c-ceEEIWA2iC__QiKGiYQhiIbeJU1Nr-uFC6UcEFA=.eff78830-d60c-43d6-a07b-263a115adb17@github.com>
Message-ID: <9HAc2av3J84YjjL6VgQLfSlMAUkicHuic2ONLc7x3ZA=.4b01d5f6-6a96-4996-bd83-be9ce5d19c41@github.com>

On Thu, 30 Jun 2022 18:32:56 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

>> This is a REDO of the Fix that was incompletely implemented earlier:
>> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
>> 
>> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
>> 
>> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
>> _(where 7200 represents 7200 seconds -> +2 hour offset)_
>> Sample output:
>> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)
>
> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288377: Simplified TZ offset calc and consolidate MACOS impl.

src/java.base/unix/native/libjava/TimeZone_md.c line 569:

> 567:     }
> 568: 
> 569:     strftime(offset, 6, "%z", &localtm);

Return value has to be examined. If it is not `5`, then I'd expect falling back to "GMT".

src/java.base/unix/native/libjava/TimeZone_md.c line 572:

> 570:     char gmt_offset[] = {offset[0], offset[1], offset[2], ':', offset[3], offset[4], '\0'};
> 571: 
> 572:     sprintf(buf, (const char *)"GMT%s", gmt_offset);

You could use the format string as "GMT%c%c%c:%c%c" so that the extra `gmt_offset` variable can be eliminated.

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

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

From naoto at openjdk.org  Thu Jun 30 20:16:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 20:16:40 GMT
Subject: <i18n dev> RFR: 8288377: [REDO] DST not applying properly with
 zone id offset set with TZ env variable
In-Reply-To: <GjL6c_nM43XFR-uz23WrJnAfPlyjbBjGR8YHL_mk--k=.b7c8c836-6e58-4314-8135-c9eeb412f941@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
 <GjL6c_nM43XFR-uz23WrJnAfPlyjbBjGR8YHL_mk--k=.b7c8c836-6e58-4314-8135-c9eeb412f941@github.com>
Message-ID: <pQJTEz5U99DoxoMhjisgoauNuKBBD_08tjhccHvNHJo=.a454b408-d0c9-4eb8-b7ed-94f2cb1bb206@github.com>

On Thu, 30 Jun 2022 18:29:42 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> One more thing to note/I'd like to make sure is what the output looks like when TZ is GMT. Want to ensure that the final string being passed down is just "GMT" and that `strftime` invocation returns an empty result. If the result is coming out to be slightly different, then it could be a problem.

You could compare GMT's hour/miute with localtime's. If they are identical, then return "GMT". For that, we may end up reviving `#if defined (MACOSX)` since macOS's tm struct has `tm_gmtoff`, but limited to that piece of code.

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

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

From naoto at openjdk.org  Thu Jun 30 22:14:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Jun 2022 22:14:10 GMT
Subject: <i18n dev> [jdk19] RFR: 8289549: ISO 4217 Amendment 172 Update
Message-ID: <szwIwxcF_DyOJa2pAznznyymjlzwQFZ6CUxnQ9514WQ=.327ba08a-82f2-42cf-9269-1510253c78ac@github.com>

Trivial fix to currency data files. The change was only made to its amendment number, as the new Sierra Leone currency has already been active with amendment 171.

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

Commit messages:
 - 8289549: ISO 4217 Amendment 172 Update

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

PR: https://git.openjdk.org/jdk19/pull/96

From iris at openjdk.org  Thu Jun 30 23:44:42 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 30 Jun 2022 23:44:42 GMT
Subject: <i18n dev> [jdk19] RFR: 8289549: ISO 4217 Amendment 172 Update
In-Reply-To: <szwIwxcF_DyOJa2pAznznyymjlzwQFZ6CUxnQ9514WQ=.327ba08a-82f2-42cf-9269-1510253c78ac@github.com>
References: <szwIwxcF_DyOJa2pAznznyymjlzwQFZ6CUxnQ9514WQ=.327ba08a-82f2-42cf-9269-1510253c78ac@github.com>
Message-ID: <UxURvZE0yIOuW77HSr9QjpUp2OxwW1M9gHCQRCZNMHU=.371997e1-2f5c-4523-8e22-2d8b6618625a@github.com>

On Thu, 30 Jun 2022 22:05:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial fix to currency data files. The change was only made to its amendment number, as the new Sierra Leone currency has already been active with amendment 171.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/96