From itakiguchi at openjdk.java.net  Wed Dec  1 08:52:31 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 1 Dec 2021 08:52:31 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <i0js_aQnY9fcrtOR0sJg9D3E2CKiAaaWDusahpaptA8=.d453694e-e5f3-4232-a2ed-8c9d2efbd85b@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
 <g3AdVBtrEbFzpNNmMp9CRTHMzKqKyqBinLLbZTCYoX4=.79dc25e3-f737-4a67-8786-e25cf4c42796@github.com>
 <i0js_aQnY9fcrtOR0sJg9D3E2CKiAaaWDusahpaptA8=.d453694e-e5f3-4232-a2ed-8c9d2efbd85b@github.com>
Message-ID: <Kfy1u61urpo-QRDMToHuaVKfqRwVwZg5bcyQmwUA-7o=.3ebc32ad-a239-4e3f-9311-759f2186a2fe@github.com>

On Mon, 29 Nov 2021 17:29:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> As I explained before, output file encoding which is created by `-Xstdout` option is changed to native encoding instead of UTF-8 by `-J-Dfile.encoding=COMPAT`.
>> In case of Linux ja_JP.eucjp locale, your explanation may be acceptable.
>> But how  about Windows platform ?
>> How can user find encoding name without running java ?
>
>> But how about Windows platform ?
> 
> If the user specifies `-J-Dfile.encoding=COMPAT`, all operations are done in `MS932` on Japanese Windows.
> 
>> How can user find encoding name without running java ?
> 
> I still don't get why the user needs to know the encoding if they specifies `COMPAT` property.

Hello @naotoj .
I discussed this issue with my colleagues.
With `-J-Dfile.encoding=COMPAT` option, the working behavior is the same as JDK17, so there is no disadvantage.
However, `-Xstdout` output file cannot be UTF8 encoded and we will not benefit from JEP-400 enhancements.
I expected that garbled character related issues could be solved easily by JEP-400 if javac command output is encoded by UTF8.
By using `-encoding` option with encoding name, javac command output can be UTF8 encoded.
But it's not easy to pick up right locale/platform encoding name except for well known users.
Anyway, when I find actual issue with `-J-Dfile.encoding=COMPAT` option for javac command, I will open new one.

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

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

From itakiguchi at openjdk.java.net  Wed Dec  1 08:52:31 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 1 Dec 2021 08:52:31 GMT
Subject: <i18n dev> Withdrawn: 8277398: javac does not accept encoding name
 COMPAT
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <Q_l9sNF3g6W_O36J9PJtTfgNdWOzFhXeDWpS0tEj4hs=.e6ebb13f-0490-4b4c-b9c0-b0e54600ba03@github.com>

On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

This pull request has been closed without being integrated.

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

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

From scolebourne at openjdk.java.net  Wed Dec  1 14:22:28 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 1 Dec 2021 14:22:28 GMT
Subject: <i18n dev> RFR: 8177819: DateTimeFormatterBuilder zone parsing
 should recognise DST [v4]
In-Reply-To: <m3UtyMyftc4fZddcVZ99ZQBLxr-DTsZxLCLt1_Y5xw8=.f65c4e7e-80c1-4d0f-b97c-0fc535055272@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
 <m3UtyMyftc4fZddcVZ99ZQBLxr-DTsZxLCLt1_Y5xw8=.f65c4e7e-80c1-4d0f-b97c-0fc535055272@github.com>
Message-ID: <IkJ_HMoGedpIUWxIILttHSXC6HPnTEOgxhS5UeJ32AE=.c476fe81-4b79-4dbf-a18c-67322e80206b@github.com>

On Mon, 29 Nov 2021 17:41:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wording. Removed `LENIENT` parser. Added tests for CI.

Marked as reviewed by scolebourne (Author).

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

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

From naoto at openjdk.java.net  Wed Dec  1 17:14:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Dec 2021 17:14:35 GMT
Subject: <i18n dev> RFR: 8277398: javac does not accept encoding name
 COMPAT [v2]
In-Reply-To: <Kfy1u61urpo-QRDMToHuaVKfqRwVwZg5bcyQmwUA-7o=.3ebc32ad-a239-4e3f-9311-759f2186a2fe@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
 <g3AdVBtrEbFzpNNmMp9CRTHMzKqKyqBinLLbZTCYoX4=.79dc25e3-f737-4a67-8786-e25cf4c42796@github.com>
 <i0js_aQnY9fcrtOR0sJg9D3E2CKiAaaWDusahpaptA8=.d453694e-e5f3-4232-a2ed-8c9d2efbd85b@github.com>
 <Kfy1u61urpo-QRDMToHuaVKfqRwVwZg5bcyQmwUA-7o=.3ebc32ad-a239-4e3f-9311-759f2186a2fe@github.com>
Message-ID: <I2TNn-94QQ1am6R53VE4rWr-Pkv_csz3SYPPWnaFFYI=.83d2b07c-6635-405a-8431-e625cbaea7df@github.com>

On Wed, 1 Dec 2021 08:49:09 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> But it's not easy to pick up right locale/platform encoding name except for well known users. 

JEP 400 has the example to get the encoding name as a one liner:

java -XshowSettings:properties -version 2>&1 | grep file.encoding

(replace `file.encoding` with `native.encoding`, if using JDK18)

I believe this is simple enough.

> Anyway, when I find actual issue with `-J-Dfile.encoding=COMPAT` option for javac command, I will open new one.

I appreciate it. Thanks.

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

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

From naoto at openjdk.java.net  Wed Dec  1 17:17:32 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Dec 2021 17:17:32 GMT
Subject: <i18n dev> Integrated: 8177819: DateTimeFormatterBuilder zone
 parsing should recognise DST
In-Reply-To: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
References: <NsvMWhhvEvq2fbaPkHeByNQwly6CrPzIizg_rkF62Q8=.b0ef99af-1ecc-4f11-8939-64f54e63a014@github.com>
Message-ID: <cfc2Curc1rV4e8k3zseGnWHHUqxZc0r3wyY5vU4C1f4=.8590b45d-234d-4136-a7ce-55d28b43fb26@github.com>

On Tue, 23 Nov 2021 17:00:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This fix intends to honor the type (std/dst/generic) of parsed zone name for selecting the offset at the overlap. Corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: a363b7b9
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a363b7b9217cbb9a7580a87b812da8d5a4215326
Stats:     204 lines in 5 files changed: 74 ins; 83 del; 47 mod

8177819: DateTimeFormatterBuilder zone parsing should recognise DST
8277049: ZonedDateTime parse in Fall DST transition fails to retain the correct zonename.

Reviewed-by: joehw, scolebourne

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

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

From bchristi at openjdk.java.net  Wed Dec  1 18:21:04 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 1 Dec 2021 18:21:04 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal [v2]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <m-ud7vTqLEF_8-DW2uxNLYZL7U0orlenSQXjZ4wmUgw=.7872b89e-a5f2-48dd-b17f-8b263fb07024@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - Fix @since on @Deprecated for java.lang.Enum
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/a363b7b9...e4986a48

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=01
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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

From bchristi at openjdk.java.net  Wed Dec  1 19:23:59 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 1 Dec 2021 19:23:59 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal [v3]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - Indicate that runFinalizers does nothing if finalization is disabled or removed
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=02
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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

From smarks at openjdk.java.net  Thu Dec  2 01:26:30 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 2 Dec 2021 01:26:30 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal [v3]
In-Reply-To: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
Message-ID: <nJKHDn0E59sPCmNw72xg_Pm22IB4JtQmufM09mM7Dek=.9e48eca8-07c1-40b2-ad90-4c8df399b59e@github.com>

On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into 8276447
>  - Merge branch 'master' into 8276447
>  - merge
>  - @SuppressWarnings(removal) in Windows CKey.java
>  - Add jls tag to runFinalization methods
>  - Update wording of Object.finalize, new paragraph is now bold
>  - update Object.finalize javadoc
>  - update Object.finalize JavaDoc and @deprecated tag
>  - Update Object.finalize deprecation message
>  - Indicate that runFinalizers does nothing if finalization is disabled or removed
>  - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

Marked as reviewed by smarks (Reviewer).

src/jdk.jconsole/share/classes/sun/tools/jconsole/SummaryTab.java line 116:

> 114:     StringBuilder buf;
> 115: 
> 116:     @SuppressWarnings("deprecation")

Item for future cleanup: refactor the call to `getObjectPendingFinalizationCount()` at line 219 (!) into a local variable declaration, and then move the warnings suppression to that declaration. This reduces the scope of warnings suppression.

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

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

From darcy at openjdk.java.net  Fri Dec  3 01:25:33 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 01:25:33 GMT
Subject: <i18n dev> RFR: JDK-8278175: Enable all doclint warnings for build
 of java.desktop
Message-ID: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>

In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

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

Commit messages:
 - JDK-8278175: Enable all doclint warnings for build of java.desktop

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

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

From jjg at openjdk.java.net  Fri Dec  3 01:41:15 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Dec 2021 01:41:15 GMT
Subject: <i18n dev> RFR: JDK-8278175: Enable all doclint warnings for
 build of java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <yjrXkkRAV00sp4zj3ioEVzJmQ1OTb6dWWYcK37P0f_c=.ac1be279-c5f8-416f-bd05-81cbfafe0b67@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Looks OK to me, although I don't consider myself a Reviewer for this code.

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

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

From duke at openjdk.java.net  Fri Dec  3 13:08:21 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 3 Dec 2021 13:08:21 GMT
Subject: <i18n dev> Integrated: 8274640: Cleanup unnecessary null comparison
 before instanceof check in java.desktop
In-Reply-To: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
References: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>
Message-ID: <nviCUnBSCr_a5OPYXWpQYR3wpwlcFJmyjqw3v5U3dBY=.0223d336-418e-4fa2-915e-915a7b884915@github.com>

On Sat, 11 Sep 2021 14:59:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Updated code checks both non-null and instance of a class in java.desktop module classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. 
> Similar cleanups
> 1. [JDK-8273484](https://bugs.openjdk.java.net/browse/JDK-8273484) java.naming
> 2. [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) java.base

This pull request has now been integrated.

Changeset: 18c54b4e
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18c54b4e1ade2ea5531054ed19441d5bff84fcdc
Stats:     526 lines in 122 files changed: 0 ins; 115 del; 411 mod

8274640: Cleanup unnecessary null comparison before instanceof check in java.desktop

Reviewed-by: aivanov

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

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

From erikj at openjdk.java.net  Fri Dec  3 13:40:22 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 3 Dec 2021 13:40:22 GMT
Subject: <i18n dev> RFR: JDK-8278175: Enable all doclint warnings for
 build of java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <8e0538sQHtH4cYq5PU1oDgvcfFiUsvtB1gD3UACkFzc=.72d78b9e-5b18-4f05-8fe6-57acaccf9a99@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

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

From naoto at openjdk.java.net  Sat Dec  4 00:08:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 4 Dec 2021 00:08:36 GMT
Subject: <i18n dev> RFR: 8275721: Name of UTC timezone in a locale changes
 depending on previous code
Message-ID: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>

Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.

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

Commit messages:
 - 8275721: Name of UTC timezone in a locale changes depending on previous code

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

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

From prr at openjdk.java.net  Sat Dec  4 00:48:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 4 Dec 2021 00:48:13 GMT
Subject: <i18n dev> RFR: JDK-8278175: Enable all doclint warnings for
 build of java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <lq-_QB_2lqzAo79lab-b5ME_S7lJYWlfGCiAumNXm8w=.c890f4f2-612d-4822-b20a-399e2010fd77@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

Looks OK. Could you file a P4 bug showing the warnings/errors that would be generated so that we know what we need to work on to later remove these the right way.

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

Marked as reviewed by prr (Reviewer).

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

From darcy at openjdk.java.net  Sat Dec  4 02:16:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 4 Dec 2021 02:16:15 GMT
Subject: <i18n dev> RFR: JDK-8278175: Enable all doclint warnings for
 build of java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <hHoiIcihO5v4zEoXp7iiAAmwEY552379dJq5puMYzp8=.5e5ce6fa-a1fe-4491-b4eb-6998e1a8c941@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

> 

Sure; filed JDK-8278254 Cleanup doclint warnings in java.desktop module

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

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

From darcy at openjdk.java.net  Sat Dec  4 02:16:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 4 Dec 2021 02:16:15 GMT
Subject: <i18n dev> Integrated: JDK-8278175: Enable all doclint warnings for
 build of java.desktop
In-Reply-To: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
References: <zOkSU1drWO9arZhgLMOTSt99P64BfTQ5XNxxFPzDuZI=.40ce3ba6-5bd4-43b0-8018-29f797bf21d6@github.com>
Message-ID: <zgNP6WHnr2gT8YTi2LlPqdYrbyyF7uBjvaJM2fSeV70=.739ab508-0f62-4bd1-a437-9826b68e50f6@github.com>

On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings. Therefore, it is now possible to enable the full doclint checks for the java.desktop module if the instances of warnings are suppressed. This patch does this; it would be preferable to address the doc warnings directly, but that is beyond what I'm attempting to do here.

This pull request has now been integrated.

Changeset: 02ee337a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02ee337ae0d163ae44b1691eb9de12c5608ba178
Stats:     34 lines in 20 files changed: 16 ins; 0 del; 18 mod

8278175: Enable all doclint warnings for build of java.desktop

Reviewed-by: erikj, prr

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

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

From naoto at openjdk.java.net  Sat Dec  4 05:46:57 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 4 Dec 2021 05:46:57 GMT
Subject: <i18n dev> RFR: 8275721: Name of UTC timezone in a locale
 changes depending on previous code [v2]
In-Reply-To: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
Message-ID: <XemM8bzfuYIOW0ATMiJngNKGoQ9lE_ocOxrcbN349wY=.641798df-c0e9-448f-844e-7fb41b58ded6@github.com>

> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.

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

  Fixed COMPAT substitution for FULL names and modified the priority.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6709/files
  - new: https://git.openjdk.java.net/jdk/pull/6709/files/10957100..3ec08e4d

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

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

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

From naoto at openjdk.java.net  Sat Dec  4 22:34:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 4 Dec 2021 22:34:50 GMT
Subject: <i18n dev> RFR: 8275721: Name of UTC timezone in a locale
 changes depending on previous code [v3]
In-Reply-To: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
Message-ID: <dyE91Fk6n3KV1ewKQfhFSdaNsl2_251vpY4zHgBJKFs=.45db5bde-695b-4472-ba9c-1da7c0f453ff@github.com>

> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.

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

  Use isFixedOffset() instead of useDaylightTime()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6709/files
  - new: https://git.openjdk.java.net/jdk/pull/6709/files/3ec08e4d..cf217f56

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

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

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

From prr at openjdk.java.net  Mon Dec  6 17:54:18 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:54:18 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v2]
In-Reply-To: <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
Message-ID: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>

On Mon, 29 Nov 2021 08:18:47 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Use Integer.signum() in BasicTableUI

src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:

> 113:          */
> 114:         public double getX1() {
> 115:             return x1;

What do these changes have to do with the subject of the PR ?

src/java.desktop/share/classes/sun/java2d/Spans.java line 322:

> 320:             float otherStart = otherSpan.getStart();
> 321: 
> 322:             return Float.compare(mStart, otherStart);

We don't need the variable any more, do we ?

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

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

From prr at openjdk.java.net  Mon Dec  6 17:57:14 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 6 Dec 2021 17:57:14 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal [v3]
In-Reply-To: <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
 <zORovjOCVMm-8yG6qtNfIrH5ICFkC5WJzL1LKMVyOJ8=.6e92825a-9fc5-4878-9659-aa70da4ed0cc@github.com>
Message-ID: <nSZ4HW0XPapNwI8DZeL4VLDLuQGT-Nl9z48R8lHsfHY=.d25aabd8-99e9-48d5-a5e0-eed809c72074@github.com>

On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
>> 
>> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
>> 
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Merge branch 'master' into 8276447
>  - Merge branch 'master' into 8276447
>  - merge
>  - @SuppressWarnings(removal) in Windows CKey.java
>  - Add jls tag to runFinalization methods
>  - Update wording of Object.finalize, new paragraph is now bold
>  - update Object.finalize javadoc
>  - update Object.finalize JavaDoc and @deprecated tag
>  - Update Object.finalize deprecation message
>  - Indicate that runFinalizers does nothing if finalization is disabled or removed
>  - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674

Marked as reviewed by prr (Reviewer).

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

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

From joehw at openjdk.java.net  Mon Dec  6 19:26:21 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 6 Dec 2021 19:26:21 GMT
Subject: <i18n dev> RFR: 8275721: Name of UTC timezone in a locale
 changes depending on previous code [v3]
In-Reply-To: <dyE91Fk6n3KV1ewKQfhFSdaNsl2_251vpY4zHgBJKFs=.45db5bde-695b-4472-ba9c-1da7c0f453ff@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
 <dyE91Fk6n3KV1ewKQfhFSdaNsl2_251vpY4zHgBJKFs=.45db5bde-695b-4472-ba9c-1da7c0f453ff@github.com>
Message-ID: <YTm5WaUORMF9XtRnIJjW4VPIcwHGzDRLIh6EBetyoDo=.3ffc7006-7288-4abd-9ad9-cc19a949d44b@github.com>

On Sat, 4 Dec 2021 22:34:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use isFixedOffset() instead of useDaylightTime()

src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java line 31:

> 29: 
> 30: import java.text.MessageFormat;
> 31: import java.time.ZoneId;

nit, the import is not used?

test/jdk/sun/util/resources/TimeZone/ChineseTimeZoneNameTest.java line 66:

> 64: 
> 65:     @Test(dataProvider="locales")
> 66:     public void test_ChineseTimeZoneNames(Locale testLoc, Locale resourceLoc) {

Does this test exercise the problem as in the original test? Do we need a test to reproduce the calling sequence as the original test?

The original issue seems to me was that the names were dependent on the order of calls, due to the name being cached. That is, if utcNameIn("zh-Hant-HK") is called first, subsequent call utcNameIn("zh-MO") would get the cached name from the call (zh-Hant-HK), but if the later is called first, it would not have the problem, that is, the following would return a correct name (??????):
utcNameIn("zh-MO"); utcNameIn("zh-Hant-HK"); utcNameIn("zh-MO");

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

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

From naoto at openjdk.java.net  Mon Dec  6 20:32:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Dec 2021 20:32:55 GMT
Subject: <i18n dev> RFR: 8275721: Name of UTC timezone in a locale
 changes depending on previous code [v4]
In-Reply-To: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
Message-ID: <1R9aClOoURgiUnve3loz2cej27KxHOsck1LgbvoimpU=.c3dc3c95-17b5-4815-a34a-d9b2d7ac7908@github.com>

> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.

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

  Removed unused import

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6709/files
  - new: https://git.openjdk.java.net/jdk/pull/6709/files/cf217f56..8f96e833

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

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

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

From naoto at openjdk.java.net  Mon Dec  6 20:41:17 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Dec 2021 20:41:17 GMT
Subject: <i18n dev> RFR: 8275721: Name of UTC timezone in a locale
 changes depending on previous code [v3]
In-Reply-To: <YTm5WaUORMF9XtRnIJjW4VPIcwHGzDRLIh6EBetyoDo=.3ffc7006-7288-4abd-9ad9-cc19a949d44b@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
 <dyE91Fk6n3KV1ewKQfhFSdaNsl2_251vpY4zHgBJKFs=.45db5bde-695b-4472-ba9c-1da7c0f453ff@github.com>
 <YTm5WaUORMF9XtRnIJjW4VPIcwHGzDRLIh6EBetyoDo=.3ffc7006-7288-4abd-9ad9-cc19a949d44b@github.com>
Message-ID: <pgz5JP-ry0BIOupfgdgEpX6XbeOOYGYM_HHBSup3Orc=.cfef893e-fd30-4298-804c-7165d62caf4d@github.com>

On Mon, 6 Dec 2021 18:52:51 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use isFixedOffset() instead of useDaylightTime()
>
> src/java.base/share/classes/sun/util/cldr/CLDRTimeZoneNameProviderImpl.java line 31:
> 
>> 29: 
>> 30: import java.text.MessageFormat;
>> 31: import java.time.ZoneId;
> 
> nit, the import is not used?

Right. Removed.

> test/jdk/sun/util/resources/TimeZone/ChineseTimeZoneNameTest.java line 66:
> 
>> 64: 
>> 65:     @Test(dataProvider="locales")
>> 66:     public void test_ChineseTimeZoneNames(Locale testLoc, Locale resourceLoc) {
> 
> Does this test exercise the problem as in the original test? Do we need a test to reproduce the calling sequence as the original test?
> 
> The original issue seems to me was that the names were dependent on the order of calls, due to the name being cached. That is, if utcNameIn("zh-Hant-HK") is called first, subsequent call utcNameIn("zh-MO") would get the cached name from the call (zh-Hant-HK), but if the later is called first, it would not have the problem, that is, the following would return a correct name (??????):
> utcNameIn("zh-MO"); utcNameIn("zh-Hant-HK"); utcNameIn("zh-MO");

`??????` is actually coming from `COMPAT` provider, which is wrong. The expected name `??????` in CLDR is in `zh-Hant` resource bundle which is not available in `COMPAT` provider. Thus, comparing `zh-MO` and `zh-Hant` names effectively asserts that the name is correctly coming from `CLDR` provider. I confirmed that this regression test did fail with the runtime without the proposed fix.

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

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

From bchristi at openjdk.java.net  Mon Dec  6 20:41:43 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 6 Dec 2021 20:41:43 GMT
Subject: <i18n dev> RFR: JDK-8276447 Deprecate finalization-related
 methods for removal [v4]
In-Reply-To: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
References: <rkKRczPheXDb7UDIQvhCRkjavYqGgUxAjlLC1-nrS_A=.03889200-fe97-4668-b622-f92bcfdb943c@github.com>
Message-ID: <yjAb3SVdTAs6VQz9haonP9y-ZnXker4ZyskjKghmwH0=.c6841727-32de-4840-94d8-4ae568a157fe@github.com>

> Here are the code changes for the "Deprecate finalizers in the standard Java API" portion of JEP 421 ("Deprecate Finalization for Removal") for code review.
> 
> This change makes the indicated deprecations, and updates the API spec for JEP 421. It also updates the relevant @SuppressWarning annotations.
> 
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - Merge branch 'master' into 8276447
 - merge
 - @SuppressWarnings(removal) in Windows CKey.java
 - Add jls tag to runFinalization methods
 - Update wording of Object.finalize, new paragraph is now bold
 - update Object.finalize javadoc
 - update Object.finalize JavaDoc and @deprecated tag
 - Update Object.finalize deprecation message
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...0a983d51

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

Changes: https://git.openjdk.java.net/jdk/pull/6465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=03
  Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465

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

From joehw at openjdk.java.net  Mon Dec  6 20:56:12 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 6 Dec 2021 20:56:12 GMT
Subject: <i18n dev> RFR: 8275721: Name of UTC timezone in a locale
 changes depending on previous code [v4]
In-Reply-To: <1R9aClOoURgiUnve3loz2cej27KxHOsck1LgbvoimpU=.c3dc3c95-17b5-4815-a34a-d9b2d7ac7908@github.com>
References: <aZj6ati58lbVLuNR1dBk2TIXedK0IrdAfXZAGRujH58=.b96a4766-a1d4-4cb0-96b5-f848f55825ad@github.com>
 <1R9aClOoURgiUnve3loz2cej27KxHOsck1LgbvoimpU=.c3dc3c95-17b5-4815-a34a-d9b2d7ac7908@github.com>
Message-ID: <mVqn2SMGJGR5JxEKEK_EFwNEwuPeuEDtP9dckE095vQ=.2f3fb939-51e0-4160-810e-71cfcc50efd2@github.com>

On Mon, 6 Dec 2021 20:32:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing time zone name provider for CLDR. In some cases, COMPAT's `UTC` display names were incorrectly substituted for CLDR. The reason it worked fine after `zh-Hant-HK` was that by loading names for `zh-Hant-HK`, the names for `zh-Hant` were cached and hit for the following `zh-MO` name retrieval.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused import

Marked as reviewed by joehw (Reviewer).

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

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

From duke at openjdk.java.net  Tue Dec  7 08:19:22 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:19:22 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v2]
In-Reply-To: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
Message-ID: <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>

On Mon, 6 Dec 2021 17:46:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:
> 
>> 113:          */
>> 114:         public double getX1() {
>> 115:             return x1;
> 
> What do these changes have to do with the subject of the PR ?

Just a tiny clean-up in on of affected files. Do you want this to be reverted?

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

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

From duke at openjdk.java.net  Tue Dec  7 08:28:47 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:28:47 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v3]
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

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

  8277868: Inline local var

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6575/files
  - new: https://git.openjdk.java.net/jdk/pull/6575/files/6744a562..1b3a5d4b

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

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

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

From duke at openjdk.java.net  Tue Dec  7 08:54:13 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 08:54:13 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v2]
In-Reply-To: <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
Message-ID: <xdI5FAZqZeQHMoHxBRdogY8q6Q3K20lfn9baQ4RHpkc=.23bdf93d-a1e4-46f0-8002-ef66029ffe1e@github.com>

On Mon, 6 Dec 2021 17:48:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Use Integer.signum() in BasicTableUI
>
> src/java.desktop/share/classes/sun/java2d/Spans.java line 322:
> 
>> 320:             float otherStart = otherSpan.getStart();
>> 321: 
>> 322:             return Float.compare(mStart, otherStart);
> 
> We don't need the variable any more, do we ?

inlined

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

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

From aivanov at openjdk.java.net  Tue Dec  7 12:28:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Dec 2021 12:28:17 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v2]
In-Reply-To: <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <IFsU28eDMPP07tV2u3Y5MhCO1_QtyPN3J1NmD2JINEo=.fa2145d4-2654-48c0-bd94-e76066bd5e0e@github.com>
 <dXlUTdI527OFijELrxPKBtWyRrngRSH6rq6j6UvXc1k=.9ba9a2ef-c2c0-4ac0-9211-24a099d57ebf@github.com>
 <M-z5np-jBcXgwf7reKgKDLkhCH5wQVIfpumzo3Vclj4=.ff1778e3-6e95-44fe-8ab8-5ed947765bdf@github.com>
Message-ID: <9S_GeeZQl7DEU-sc0rPTWTs-rECNOmwEQRsj-zMotqU=.4f156b22-5909-4451-8652-9af749bb288f@github.com>

On Tue, 7 Dec 2021 08:16:08 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> src/java.desktop/share/classes/java/awt/geom/Line2D.java line 115:
>> 
>>> 113:          */
>>> 114:         public double getX1() {
>>> 115:             return x1;
>> 
>> What do these changes have to do with the subject of the PR ?
>
> Just a tiny clean-up in on of affected files. Do you want this to be reverted?

I believe it makes to preserve the cast: the fields are of type `float` and explicit cast hints there's a type conversion.

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

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

From aivanov at openjdk.java.net  Tue Dec  7 12:28:17 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 7 Dec 2021 12:28:17 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v3]
In-Reply-To: <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
Message-ID: <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>

On Tue, 7 Dec 2021 08:28:47 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Inline local var

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

> 3418:     private int compareTo(long t) {
> 3419:         long thisTime = getMillisOf(this);
> 3420:         return Long.compare(thisTime, t);

Probably, in this case `thisTime` variable can also be dropped.

src/java.base/share/classes/java/util/Date.java line 977:

> 975:         long thisTime = getMillisOf(this);
> 976:         long anotherTime = getMillisOf(anotherDate);
> 977:         return Long.compare(thisTime, anotherTime);

Looks like local variables can also be dropped here as each value is used once.

src/java.base/share/classes/java/util/UUID.java line 517:

> 515:         return (this.mostSigBits < val.mostSigBits ? -1 :
> 516:                 (this.mostSigBits > val.mostSigBits ? 1 :
> 517:                  Long.compare(this.leastSigBits, val.leastSigBits)));

In this case Javadoc specifies only -1, 0 or 1 can be returned. `Long.compare` does not specify this but returns these values. Couldn't it cause any problems in the future if implementation of `Long.compare` is changed?

Does it make sense to use `Long.compare` for `mostSigBits` too?

int mostSigBits = Long.compare(this.mostSigBits, val.mostSigBits);
return mostSigBits != 0 ? mostSigBits : Long.compare(this.leastSigBits, val.leastSigBits);

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

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

From duke at openjdk.java.net  Tue Dec  7 14:39:51 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 14:39:51 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v3]
In-Reply-To: <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <HTd3akuVxFHjNnOqUf1gEFBr67raD8-XU8KZWXlicIo=.6836f96c-3fee-40fd-8c3d-8ee92fa69654@github.com>
 <qzfCWMEJDBk5Yykg-AmLOT1lSOgq6zKYWDwj8cXBi8M=.a040086d-8e24-42fa-ad45-8bd917a22799@github.com>
Message-ID: <RfAx0opkX4lKUfu0edbgotzC4KFnDpeipa3-1_109mI=.232d9ebe-15be-475f-a720-c6165dcb0b3c@github.com>

On Tue, 7 Dec 2021 12:01:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277868: Inline local var
>
> src/java.base/share/classes/java/util/Calendar.java line 3420:
> 
>> 3418:     private int compareTo(long t) {
>> 3419:         long thisTime = getMillisOf(this);
>> 3420:         return Long.compare(thisTime, t);
> 
> Probably, in this case `thisTime` variable can also be dropped.

Inlined

> src/java.base/share/classes/java/util/Date.java line 977:
> 
>> 975:         long thisTime = getMillisOf(this);
>> 976:         long anotherTime = getMillisOf(anotherDate);
>> 977:         return Long.compare(thisTime, anotherTime);
> 
> Looks like local variables can also be dropped here as each value is used once.

Inlined

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

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

From duke at openjdk.java.net  Tue Dec  7 14:39:46 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 7 Dec 2021 14:39:46 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v4]
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <6H721EvqNvo4S4PAIRiqFgVtORHDFVjUW_nQ3LJIdvM=.685ca0ab-0ba9-4501-9e4e-6de9ca93be51@github.com>

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

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

 - 8277868: Revert irrelevant changes
 - 8277868: Inline local vars

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6575/files
  - new: https://git.openjdk.java.net/jdk/pull/6575/files/1b3a5d4b..bb06bf2f

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

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

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

From serb at openjdk.java.net  Fri Dec 10 00:57:17 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 10 Dec 2021 00:57:17 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v4]
In-Reply-To: <4-SKWxMIwTELnjjaNtCMiLopBp2n1-vpCPnEl4Gst6s=.e04c81b2-d0ed-4366-9b5b-f3eac4a660a5@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <4-SKWxMIwTELnjjaNtCMiLopBp2n1-vpCPnEl4Gst6s=.e04c81b2-d0ed-4366-9b5b-f3eac4a660a5@github.com>
Message-ID: <fXbwLrE2CuWWr93ompLDx5VakFv-l9emVh-7ISDZowU=.9f5cfd64-7f5e-45bf-886b-7f0a1a24a858@github.com>

On Tue, 23 Nov 2021 20:52:40 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> 8274893: Update java.desktop classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274893: Update java.desktop classes to use try-with-resources
>   close nested streams too to unify code

Marked as reviewed by serb (Reviewer).

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

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

From redestad at openjdk.java.net  Tue Dec 14 14:58:22 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 14 Dec 2021 14:58:22 GMT
Subject: <i18n dev> RFR: 8278642: Refactor java.util.Formatter
Message-ID: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>

A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:

- turn `Flags` into an `int` (fewer allocations in the complex case)
- remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
- make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.

Baseline: 

Benchmark                                                           Mode  Cnt     Score     Error   Units
StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op


Patch:

Benchmark                                                           Mode  Cnt     Score    Error   Units
StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

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

Commit messages:
 - Fix call with null Formatter
 - 8278642: Refactor Formatter

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

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

From rriggs at openjdk.java.net  Wed Dec 15 20:12:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 15 Dec 2021 20:12:55 GMT
Subject: <i18n dev> RFR: 8278642: Refactor java.util.Formatter
In-Reply-To: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
Message-ID: <K5xoJTBTkA7NviQ0KU0OG09ZqQkoHwQLYwoj48xbjNo=.402afa04-361e-4da7-a9be-c791ae286847@github.com>

On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
> 
> - turn `Flags` into an `int` (fewer allocations in the complex case)
> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
> 
> Baseline: 
> 
> Benchmark                                                           Mode  Cnt     Score     Error   Units
> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
> 
> 
> Patch:
> 
> Benchmark                                                           Mode  Cnt     Score    Error   Units
> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

Looks good to me.  Not a big improvement, but as much as it gets used.  ??

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

Marked as reviewed by rriggs (Reviewer).

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

From naoto at openjdk.java.net  Wed Dec 15 21:39:01 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 15 Dec 2021 21:39:01 GMT
Subject: <i18n dev> RFR: 8278642: Refactor java.util.Formatter
In-Reply-To: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
Message-ID: <ncuWrX9JcktmM8Lg5yGXHzMs2Gb4PysShqpV0nhVNSM=.c757c636-7e63-43cd-ae58-8f1a50e4804f@github.com>

On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
> 
> - turn `Flags` into an `int` (fewer allocations in the complex case)
> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
> 
> Baseline: 
> 
> Benchmark                                                           Mode  Cnt     Score     Error   Units
> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
> 
> 
> Patch:
> 
> Benchmark                                                           Mode  Cnt     Score    Error   Units
> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

LGTM. I'd be tempted to replace those `instanceof`s with pattern-match to get rid of castings, but that's not inherent to this issue.

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

Marked as reviewed by naoto (Reviewer).

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

From redestad at openjdk.java.net  Wed Dec 15 23:03:58 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 15 Dec 2021 23:03:58 GMT
Subject: <i18n dev> RFR: 8278642: Refactor java.util.Formatter
In-Reply-To: <K5xoJTBTkA7NviQ0KU0OG09ZqQkoHwQLYwoj48xbjNo=.402afa04-361e-4da7-a9be-c791ae286847@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
 <K5xoJTBTkA7NviQ0KU0OG09ZqQkoHwQLYwoj48xbjNo=.402afa04-361e-4da7-a9be-c791ae286847@github.com>
Message-ID: <ZYcS8UOuNxL3K7C8iTw3a6Eu7nUOLQg7VJYmnWGoowE=.bfb90dcc-66f1-4e1c-9ba2-749b65c2bf38@github.com>

On Wed, 15 Dec 2021 20:09:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
>> 
>> - turn `Flags` into an `int` (fewer allocations in the complex case)
>> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
>> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
>> 
>> Baseline: 
>> 
>> Benchmark                                                           Mode  Cnt     Score     Error   Units
>> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
>> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
>> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
>> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
>> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
>> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
>> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
>> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
>> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
>> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                                           Mode  Cnt     Score    Error   Units
>> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
>> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
>> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
>> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
>> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
>> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
>> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
>> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
>> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
>> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op
>
> Looks good to me.  Not a big improvement, but as much as it gets used.  ??

Thanks for reviews, @RogerRiggs and @naotoj ! 

Yes, the speed-up is a bit underwhelming. I had to dial back some more promising optimizations I was exploring (#6792) after realizing they'd be breaking semantics in case of an illegal format string. These are the cleanups and pile-on optimizations I could salvage from that experiment, along with some harmonization with changes @JimLaskey is doing for TemplatedStrings.

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

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

From redestad at openjdk.java.net  Thu Dec 16 11:49:59 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 16 Dec 2021 11:49:59 GMT
Subject: <i18n dev> RFR: 8278642: Refactor java.util.Formatter
In-Reply-To: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
Message-ID: <uu4PU0ezVUE7Qy7-aLBU6aEnT7xrFpwncLtFm9jVwCY=.235db977-f507-4c54-80f9-8f1fe5cc9138@github.com>

On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
> 
> - turn `Flags` into an `int` (fewer allocations in the complex case)
> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
> 
> Baseline: 
> 
> Benchmark                                                           Mode  Cnt     Score     Error   Units
> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
> 
> 
> Patch:
> 
> Benchmark                                                           Mode  Cnt     Score    Error   Units
> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

Re-ran tier1+2 in our CI due to the mystery error in GHA testing. All passed.

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

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

From redestad at openjdk.java.net  Thu Dec 16 11:49:59 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 16 Dec 2021 11:49:59 GMT
Subject: <i18n dev> Integrated: 8278642: Refactor java.util.Formatter
In-Reply-To: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
References: <rx5r-H-nwcJhNlVGJHOoTiaTbXrmRThaEfmwe3fDr5k=.53b73008-22ca-40b4-8e37-c4343467f664@github.com>
Message-ID: <qaJKA2VauCqOAoKCB_D_uiagh93BK0AMCEnbdVeVTHQ=.98aa989c-a0b6-44c9-bcf8-96345ff215cf@github.com>

On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
> 
> - turn `Flags` into an `int` (fewer allocations in the complex case)
> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
> 
> Baseline: 
> 
> Benchmark                                                           Mode  Cnt     Score     Error   Units
> StringFormat.complexFormat                                          avgt   25  8977.043 ? 246.810   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  2144.170 ?   0.012    B/op
> StringFormat.stringFormat                                           avgt   25   252.109 ?   2.732   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   256.019 ?   0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   576.423 ?   4.596   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   432.034 ?   0.002    B/op
> StringFormat.widthStringFormat                                      avgt   25   999.835 ?  20.127   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   525.509 ?  14.742    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ?  30.901   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   720.715 ?   8.798    B/op
> 
> 
> Patch:
> 
> Benchmark                                                           Mode  Cnt     Score    Error   Units
> StringFormat.complexFormat                                          avgt   25  8840.089 ? 51.222   ns/op
> StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt   25  1736.151 ?  0.009    B/op
> StringFormat.stringFormat                                           avgt   25   247.310 ?  2.091   ns/op
> StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt   25   248.018 ?  0.001    B/op
> StringFormat.stringIntFormat                                        avgt   25   565.487 ?  6.572   ns/op
> StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt   25   408.032 ?  0.002    B
> StringFormat.widthStringFormat                                      avgt   25   970.015 ? 32.915   ns/op
> StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt   25   449.991 ? 25.716    B/op
> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ? 28.829   ns/op
> StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt   25   636.872 ?  7.331    B/op

This pull request has now been integrated.

Changeset: aae56398
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aae563981c89d922c51005626b39c31e377cadc5
Stats:     333 lines in 1 file changed: 0 ins; 39 del; 294 mod

8278642: Refactor java.util.Formatter

Reviewed-by: rriggs, naoto

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

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

From naoto at openjdk.java.net  Thu Dec 16 19:56:20 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 16 Dec 2021 19:56:20 GMT
Subject: <i18n dev> RFR: 8278434: timeouts in test
 java/time/test/java/time/format/TestZoneTextPrinterParser.java
Message-ID: <TQOaPuDzIsAzUX5MjisR5RgnyIbE9fKQ4lWMfpCbLTA=.55e5ef68-ff89-4060-87fd-1ddef592987a@github.com>

The proposed fix is to address the performance degradation caused by the fix to JDK-8275721. Some amount of the degradation cannot be avoided as the lookup now falls back up to the bundles at Locale.ROOT. However, by lowering the fallback priority of `regionFormatFallback` than `COMPAT`'s lookup, it can avoid the excess bundle lookups for regions.
I also changed the test case `TestZoneTextPrinterParser.java`, which currently iterates over 3 nested loops, i.e., all-locales x all-timezones x 8, which is absolutely unnecessary. Made it to sample some locales.
In addition, I added a microbenchmark for the DateFormatSymbols.getZoneStrings() method. Here is the result:

Before the fix to JDK-8275721:

Benchmark                    Mode  Cnt  Score   Error  Units
ZoneStrings.testZoneStrings    ss    5  6.865 ? 0.696   s/op

Before the proposed fix:

Benchmark                    Mode  Cnt   Score   Error  Units
ZoneStrings.testZoneStrings    ss    5  15.741 ? 4.300   s/op

After the proposed fix:

Benchmark                    Mode  Cnt  Score   Error  Units
ZoneStrings.testZoneStrings    ss    5  9.756 ? 3.685   s/op

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

Commit messages:
 - Added a microbenchmark for zone strings
 - 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java

Changes: https://git.openjdk.java.net/jdk/pull/6790/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6790&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8278434
  Stats: 72 lines in 3 files changed: 59 ins; 7 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6790.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6790/head:pull/6790

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

From duke at openjdk.java.net  Thu Dec 16 21:42:05 2021
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 16 Dec 2021 21:42:05 GMT
Subject: <i18n dev> Integrated: 8277868: Use Comparable.compare() instead of
 surrogate code
In-Reply-To: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
Message-ID: <5ZOhPiacNs5fjMH_6weWYlaPWVSqPMvRAXY2iT_6T68=.3e2499b4-45e6-497c-b5c0-d549d7c324e2@github.com>

On Fri, 26 Nov 2021 12:46:59 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> Instead of something like
> 
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
> 
> we can use `return Long.compare(x, y);`
> 
> All replacements are done with IDE.

This pull request has now been integrated.

Changeset: 20db7800
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/20db7800a657b311eeac504a2bbae4adbc209dbf
Stats:     77 lines in 12 files changed: 2 ins; 54 del; 21 mod

8277868: Use Comparable.compare() instead of surrogate code

Reviewed-by: rriggs, aivanov

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

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

From rriggs at openjdk.java.net  Fri Dec 17 15:06:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 17 Dec 2021 15:06:27 GMT
Subject: <i18n dev> RFR: 8277868: Use Comparable.compare() instead of
 surrogate code [v6]
In-Reply-To: <Oi8A_LWOae14543lPHb3inUSq4s3yF9GRmu5qQdmqh0=.82cc5f87-bb16-420a-8222-03fe6631a29e@github.com>
References: <PhNnczC1g5SV60omChE2_ctUflo95NWLJEgRXAy2zfE=.9afb7196-40cf-469b-bc00-410716ef26af@github.com>
 <Oi8A_LWOae14543lPHb3inUSq4s3yF9GRmu5qQdmqh0=.82cc5f87-bb16-420a-8222-03fe6631a29e@github.com>
Message-ID: <GxSLYrrtSHkak2yRopMZZvKVbrsN7qFo-2BmNFUANt8=.aff00657-cdd8-4d5c-b57a-096d3fa68d08@github.com>

On Thu, 9 Dec 2021 13:03:39 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8277868: Use Long.compare() for mostSigBits as well
>  - Revert "8277868: Adjust JavaDoc of UUID"
>    
>    This reverts commit f3b95d0e247cf6452955f4f24684fd60d5cb8902.

As it turns out replacing the code was not 100% equivalent and a test failure resulted.
See https://bugs.openjdk.java.net/browse/JDK-8278937

Double.compare and the original code handle the non-numeric forms of Double differently.

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

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

From duke at openjdk.java.net  Mon Dec 20 02:49:41 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Mon, 20 Dec 2021 02:49:41 GMT
Subject: <i18n dev> RFR: JDK-8276302: Locale.filterTags methods ignore
 actual weight when matching "*" (as if it is 1)
Message-ID: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>

Locale.filterTags methods ignore actual weight when matching "*" (as if
it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.

Fix the bug and add regression test cases for it as well as existing
behavior.

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

Commit messages:
 - Locale.filterTags must respect the weight of "*"

Changes: https://git.openjdk.java.net/jdk/pull/6789/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6789&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276302
  Stats: 121 lines in 2 files changed: 59 ins; 54 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6789.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6789/head:pull/6789

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

From naoto at openjdk.java.net  Mon Dec 20 18:33:11 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 20 Dec 2021 18:33:11 GMT
Subject: <i18n dev> RFR: JDK-8276302: Locale.filterTags methods ignore
 actual weight when matching "*" (as if it is 1)
In-Reply-To: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
Message-ID: <A4RNOmrkDldnRBvFNYoHZ1Q_4Km9xRaSdhRNQAXS7eE=.2f33d15f-8afa-457a-85e0-4eda9a08a8c4@github.com>

On Fri, 10 Dec 2021 00:02:31 GMT, Daniel Le <duke at openjdk.java.net> wrote:

> Locale.filterTags methods ignore actual weight when matching "*" (as if
> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
> 
> Fix the bug and add regression test cases for it as well as existing
> behavior.

Thanks for the fix. Looks good overall. Some minor comments follow. Also for the test case,
- add the bug id `8276302` to the `@bug` tag.
- modify the copyright year to 2021.

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 131:

> 129: 
> 130:                     if (!caseInsensitiveMatch(list, lowerCaseTag)
> 131:                             && !shouldIgnoreFilterBasicMatch(zeroRanges, lowerCaseTag)) {

Is there any reason to flip the evaluation order of the `if` statement?

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 157:

> 155:      * returning all the tags, remove those which are matching the range with
> 156:      * quality weight q=0.
> 157:      */

Please keep the comments in the modified code (except the `*` part). Although it's OK to remove this method as it eliminates extra `ArrayList` allocation, please keep the comments in the modified code (except the `*` part).

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 161:

> 159:             List<LanguageRange> zeroRange, Collection<String> tags) {
> 160:         if (zeroRange.isEmpty()) {
> 161:             tags = removeDuplicates(tags);

Can `removeDuplicates()` now be removed? There seems to be no usage.

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

> 165:         List<String> matchingTags = new ArrayList<>();
> 166:         for (String tag : tags) {
> 167:             // change to lowercase for case-insensitive matching

Applies to this comment.

src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 171:

> 169:             if (!shouldIgnoreFilterBasicMatch(zeroRange, lowerCaseTag)
> 170:                     && !caseInsensitiveMatch(matchingTags, lowerCaseTag)) {
> 171:                 matchingTags.add(tag); // preserving the case of the input tag

And this comment, too.

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

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

From duke at openjdk.java.net  Wed Dec 22 07:33:55 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Wed, 22 Dec 2021 07:33:55 GMT
Subject: <i18n dev> RFR: JDK-8276302: Locale.filterTags methods ignore
 actual weight when matching "*" (as if it is 1) [v2]
In-Reply-To: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
Message-ID: <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>

> Locale.filterTags methods ignore actual weight when matching "*" (as if
> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
> 
> Fix the bug and add regression test cases for it as well as existing
> behavior.

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

  Address most review comments
  
  - Include "// change to lowercase for case-insensitive matching" and "//
    preserving the case of the input tag" in the if branch in the for loop
    of LocaleMatcher.{filterBasic,filterExtended}
  
  - Remove LocaleMatcher.removeDuplicates since is it no longer used
  
  - For Bug7069824.java, add 8276302 to the @bug tag and update the
    copyright year to 2021
  
  https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6789/files
  - new: https://git.openjdk.java.net/jdk/pull/6789/files/85d71141..c3abb980

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

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

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

From duke at openjdk.java.net  Wed Dec 22 07:44:19 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Wed, 22 Dec 2021 07:44:19 GMT
Subject: <i18n dev> RFR: JDK-8276302: Locale.filterTags methods ignore
 actual weight when matching "*" (as if it is 1) [v2]
In-Reply-To: <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
 <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>
Message-ID: <fPVNFVfbz9RgxD3xTTqkBVfS8lIvFVzpJR2X7KLdbrc=.40b1cc92-bd5e-436d-a5ea-f0010928abb5@github.com>

On Wed, 22 Dec 2021 07:33:55 GMT, Daniel Le <duke at openjdk.java.net> wrote:

>> Locale.filterTags methods ignore actual weight when matching "*" (as if
>> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
>> 
>> Fix the bug and add regression test cases for it as well as existing
>> behavior.
>
> Daniel Le has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address most review comments
>   
>   - Include "// change to lowercase for case-insensitive matching" and "//
>     preserving the case of the input tag" in the if branch in the for loop
>     of LocaleMatcher.{filterBasic,filterExtended}
>   
>   - Remove LocaleMatcher.removeDuplicates since is it no longer used
>   
>   - For Bug7069824.java, add 8276302 to the @bug tag and update the
>     copyright year to 2021
>   
>   https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415

I've addressed most of your comments in https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415 except for https://github.com/openjdk/jdk/pull/6789/files#r772577336. Thank you.

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

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

From duke at openjdk.java.net  Wed Dec 22 07:44:22 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Wed, 22 Dec 2021 07:44:22 GMT
Subject: <i18n dev> RFR: JDK-8276302: Locale.filterTags methods ignore
 actual weight when matching "*" (as if it is 1) [v2]
In-Reply-To: <A4RNOmrkDldnRBvFNYoHZ1Q_4Km9xRaSdhRNQAXS7eE=.2f33d15f-8afa-457a-85e0-4eda9a08a8c4@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
 <A4RNOmrkDldnRBvFNYoHZ1Q_4Km9xRaSdhRNQAXS7eE=.2f33d15f-8afa-457a-85e0-4eda9a08a8c4@github.com>
Message-ID: <GSZqhE7VJ4P5G5j5IDUz634s6XAEb7PlgisB3ZLX_Y0=.098ee3f3-b663-488d-a733-12be2dd62b78@github.com>

On Mon, 20 Dec 2021 18:18:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Daniel Le has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address most review comments
>>   
>>   - Include "// change to lowercase for case-insensitive matching" and "//
>>     preserving the case of the input tag" in the if branch in the for loop
>>     of LocaleMatcher.{filterBasic,filterExtended}
>>   
>>   - Remove LocaleMatcher.removeDuplicates since is it no longer used
>>   
>>   - For Bug7069824.java, add 8276302 to the @bug tag and update the
>>     copyright year to 2021
>>   
>>   https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415
>
> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 131:
> 
>> 129: 
>> 130:                     if (!caseInsensitiveMatch(list, lowerCaseTag)
>> 131:                             && !shouldIgnoreFilterBasicMatch(zeroRanges, lowerCaseTag)) {
> 
> Is there any reason to flip the evaluation order of the `if` statement?

Two reasons:
  - It's consistent with the `else`  branch in the `for` loop of `LocaleMatcher.{filterBasic,filterExtended}` (main)
  - I thought that `caseInsensitiveMatch` being first made it clear the need for `lowerCaseTag` but now noticed that the comment was meant for `{shouldIgnoreFilterBasicMatch,shouldIgnoreFilterExtendedMatch}` instead

> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 157:
> 
>> 155:      * returning all the tags, remove those which are matching the range with
>> 156:      * quality weight q=0.
>> 157:      */
> 
> Please keep the comments in the modified code (except the `*` part). Although it's OK to remove this method as it eliminates extra `ArrayList` allocation, please keep the comments in the modified code (except the `*` part).

I've tried to follow your suggestion but I think this comment is no longer necessary. (The tags are no longer removed and no collections are updated.)

I had noticed that this comment could not be added back verbatim to the modified code. Hence, I tried to rewrite it. However, I noticed that the comments for `LocaleMatcher{shouldIgnoreFilterBasicMatch,shouldIgnoreFilterExtendedMatch}` clearly covers what we wanted to highlight here.

Let me know if you disagree together with a comment that you'd like me to include verbatim.

> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 161:
> 
>> 159:             List<LanguageRange> zeroRange, Collection<String> tags) {
>> 160:         if (zeroRange.isEmpty()) {
>> 161:             tags = removeDuplicates(tags);
> 
> Can `removeDuplicates()` now be removed? There seems to be no usage.

Done.

> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 167:
> 
>> 165:         List<String> matchingTags = new ArrayList<>();
>> 166:         for (String tag : tags) {
>> 167:             // change to lowercase for case-insensitive matching
> 
> Applies to this comment.

Done.

> src/java.base/share/classes/sun/util/locale/LocaleMatcher.java line 171:
> 
>> 169:             if (!shouldIgnoreFilterBasicMatch(zeroRange, lowerCaseTag)
>> 170:                     && !caseInsensitiveMatch(matchingTags, lowerCaseTag)) {
>> 171:                 matchingTags.add(tag); // preserving the case of the input tag
> 
> And this comment, too.

Done.

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

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

From naoto at openjdk.java.net  Wed Dec 22 17:52:13 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 22 Dec 2021 17:52:13 GMT
Subject: <i18n dev> RFR: JDK-8276302: Locale.filterTags methods ignore
 actual weight when matching "*" (as if it is 1) [v2]
In-Reply-To: <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
 <l-LD4h7y-leJQNS5eAjBtZAkPQmjktqQueSLWmL-Woo=.e0299558-cdd9-4d62-ae89-10faa2d12221@github.com>
Message-ID: <lr1D7AHXylo1RIu2RKOB3LZw2ZADPN9sfE9MesQrzBc=.2eb1bb38-bac0-4eb3-9bc6-5e2113e63168@github.com>

On Wed, 22 Dec 2021 07:33:55 GMT, Daniel Le <duke at openjdk.java.net> wrote:

>> Locale.filterTags methods ignore actual weight when matching "*" (as if
>> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
>> 
>> Fix the bug and add regression test cases for it as well as existing
>> behavior.
>
> Daniel Le has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address most review comments
>   
>   - Include "// change to lowercase for case-insensitive matching" and "//
>     preserving the case of the input tag" in the if branch in the for loop
>     of LocaleMatcher.{filterBasic,filterExtended}
>   
>   - Remove LocaleMatcher.removeDuplicates since is it no longer used
>   
>   - For Bug7069824.java, add 8276302 to the @bug tag and update the
>     copyright year to 2021
>   
>   https://github.com/openjdk/jdk/pull/6789#pullrequestreview-836689415

Thanks for the changes. Those all look good. I will sponsor this PR once it is integrated.

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

Marked as reviewed by naoto (Reviewer).

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

From duke at openjdk.java.net  Thu Dec 23 14:15:25 2021
From: duke at openjdk.java.net (Daniel Le)
Date: Thu, 23 Dec 2021 14:15:25 GMT
Subject: <i18n dev> Integrated: JDK-8276302: Locale.filterTags methods
 ignore actual weight when matching "*" (as if it is 1)
In-Reply-To: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
References: <XCrg_zI4GozQ7dB9GswNyxRbkuRNZ0BAYMAoHhYGH_0=.be23129a-176f-4b67-bbd1-67e426840ab2@github.com>
Message-ID: <Ja4XWfocBad0_8vnXUizG1uKL_8yy_3NMyxqTci-I18=.e6cc0a6e-50a7-483c-8bbe-f50df0897676@github.com>

On Fri, 10 Dec 2021 00:02:31 GMT, Daniel Le <duke at openjdk.java.net> wrote:

> Locale.filterTags methods ignore actual weight when matching "*" (as if
> it is 1) because LocaleMatcher.{filterBasic,filterExtended} do so.
> 
> Fix the bug and add regression test cases for it as well as existing
> behavior.

This pull request has now been integrated.

Changeset: 87cc4e50
Author:    Daniel Le <greenrecyclebin at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/87cc4e5009f6b900c62a91dda1c2f98e4821a492
Stats:     138 lines in 2 files changed: 63 ins; 65 del; 10 mod

8276302: Locale.filterTags methods ignore actual weight when matching "*" (as if it is 1)

Reviewed-by: naoto

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

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

From duke at openjdk.java.net  Fri Dec 24 02:06:18 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 24 Dec 2021 02:06:18 GMT
Subject: <i18n dev> Integrated: 8274893: Update java.desktop classes to use
 try-with-resources
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <JL4t9fjYx65gUMm9OPILuDc6RrzQ7Xwxs6LEMcmg1zU=.2e61061a-212e-45d9-b61b-a8dc21fd94b6@github.com>

On Tue, 5 Oct 2021 08:13:53 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8274893: Update java.desktop classes to use try-with-resources

This pull request has now been integrated.

Changeset: 70c6df6b
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70c6df6be431fe11c5441986ed04040f9ec3b750
Stats:     227 lines in 24 files changed: 27 ins; 98 del; 102 mod

8274893: Update java.desktop classes to use try-with-resources

Reviewed-by: serb

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

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