From cgo at openjdk.java.net  Mon Mar  1 15:24:43 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 1 Mar 2021 15:24:43 GMT
Subject: <i18n dev> RFR: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <zYXYhx46bm8g_dYCTXxlnrIIoOldQwc7giadIrKOxao=.22da3a8e-6349-473f-8015-a64488572469@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
 <zYXYhx46bm8g_dYCTXxlnrIIoOldQwc7giadIrKOxao=.22da3a8e-6349-473f-8015-a64488572469@github.com>
Message-ID: <WioKjap6ADDAdX_tFW3B7fwKuVaihCNA7P2yvMlZW9A=.4aa81ba1-821f-4c46-a32d-317c164c3336@github.com>

On Sat, 27 Feb 2021 08:03:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java
>
> Looks fine. This source file was a .template until a few weeks ago, probably should have fixed the indentation issues when moving it to a .java file.

Thanks for the review.
Do we need a second reviewer? If not, could you please sponsor the change?

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

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

From redestad at openjdk.java.net  Fri Mar  5 16:02:29 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 16:02:29 GMT
Subject: <i18n dev> RFR: 8263091: Remove
 CharacterData.isOtherUppercase/-Lowercase
Message-ID: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>

This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.

I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

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

Commit messages:
 - Fold CharacterData.isOtherUpper-/Lowercase into isUpper-/LowerCase

Changes: https://git.openjdk.java.net/jdk/pull/2846/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2846&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263091
  Stats: 98 lines in 8 files changed: 1 ins; 71 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2846.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2846/head:pull/2846

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

From redestad at openjdk.java.net  Fri Mar  5 16:02:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 16:02:42 GMT
Subject: <i18n dev> RFR: 8263091: Remove
 CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <O2izZ1umCuor3NLuKOQoP-XxKENBh3Cp2jvBv3JbilU=.2101b6ee-dddf-40d5-a9cb-5c123bd88cfd@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

Microbenchmark results, org.openjdk.bench.java.lang.Characters

OOTB:
Benchmark               (codePoint)  Mode  Cnt   Score   Error  Units
Characters.isLowerCase          176  avgt    5  13.812 ? 0.060  ns/op
Characters.isUpperCase          176  avgt    5  13.812 ? 0.062  ns/op

Benchmark               (codePoint)  Mode  Cnt   Score   Error  Units
Characters.isLowerCase          176  avgt    5  13.825 ? 0.096  ns/op
Characters.isUpperCase          176  avgt    5  12.555 ? 0.033  ns/op
~1.1x speed-up for Character.isUpperCase in the latin 1 range

-Xint:
Benchmark               (codePoint)  Mode  Cnt    Score    Error  Units
Characters.isLowerCase          176  avgt    5  754.756 ? 20.815  ns/op
Characters.isUpperCase          176  avgt    5  755.403 ? 15.645  ns/op

Benchmark               (codePoint)  Mode  Cnt    Score   Error  Units
Characters.isLowerCase          176  avgt    5  606.923 ? 1.569  ns/op
Characters.isUpperCase          176  avgt    5  521.073 ? 7.439  ns/op
1.25x speed-up for isLowerCase and 1.45x speed-up for isUpperCase when interpreting, translating to minor startup / warmup win on some examined apps.

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

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

From redestad at openjdk.java.net  Fri Mar  5 16:05:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 16:05:57 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <EWJC3tddBAKgivUj0vL70irZShN4dqXulLLkAHu8Ffg=.89f05c27-45b9-4a17-b120-1c5aff4fb582@github.com>

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

Results on the provided, simple microbenchmark

Baseline:
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    5  11.142 ? 0.084  ns/op
LocaleDefaults.getDefaultDisplay  avgt    5  14.024 ? 0.063  ns/op
LocaleDefaults.getDefaultFormat   avgt    5  14.001 ? 0.072  ns/op
Patch:
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    5  11.210 ? 0.057  ns/op
LocaleDefaults.getDefaultDisplay  avgt    5  12.597 ? 0.022  ns/op
LocaleDefaults.getDefaultFormat   avgt    5  12.608 ? 0.049  ns/op

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

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

From redestad at openjdk.java.net  Fri Mar  5 16:05:54 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 16:05:54 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
Message-ID: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>

This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

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

Commit messages:
 - Add microbenchmark
 - Reduce volatile reads in Locale.getDefault(Category)

Changes: https://git.openjdk.java.net/jdk/pull/2845/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2845&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263090
  Stats: 92 lines in 2 files changed: 72 ins; 5 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2845/head:pull/2845

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

From rriggs at openjdk.java.net  Fri Mar  5 17:19:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 5 Mar 2021 17:19:06 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <S0enrGp7NE314TyzvIvfR91dEyJniWIV2sQA3JTMcD8=.d5b562dd-65e2-4272-9145-739851817988@github.com>

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

Marked as reviewed by rriggs (Reviewer).

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

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

From rriggs at openjdk.java.net  Fri Mar  5 17:22:07 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 5 Mar 2021 17:22:07 GMT
Subject: <i18n dev> RFR: 8263091: Remove
 CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <6T0y3MQwo4256VsX9FBxM0QaDwI4FXqn_IBv1PVOBGg=.8c53ab06-617e-4d2c-9a2a-7361e449ad12@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

Marked as reviewed by rriggs (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Mar  5 17:32:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 5 Mar 2021 17:32:06 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <PGnyOMqtHpgWAEG1JAKP5oX6T1JHG9ZEvBLJxRnXfvQ=.9c69f8b3-646b-4941-b344-f5d8e5b85219@github.com>

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

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

> 957:     }
> 958: 
> 959:     private static Locale getDisplayLocale() {

Should this be `synchronized`?

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

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

From naoto at openjdk.java.net  Fri Mar  5 17:56:15 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 5 Mar 2021 17:56:15 GMT
Subject: <i18n dev> RFR: 8263091: Remove
 CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <4BKu3uO5Oz4Lni3HAa3fbG4bv3hUKFjlAiLWQpNyskE=.a6fb7a27-629b-4b95-a972-a5e02f0653f9@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

Marked as reviewed by naoto (Reviewer).

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

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

From redestad at openjdk.java.net  Fri Mar  5 18:53:30 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 18:53:30 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <PGnyOMqtHpgWAEG1JAKP5oX6T1JHG9ZEvBLJxRnXfvQ=.9c69f8b3-646b-4941-b344-f5d8e5b85219@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <PGnyOMqtHpgWAEG1JAKP5oX6T1JHG9ZEvBLJxRnXfvQ=.9c69f8b3-646b-4941-b344-f5d8e5b85219@github.com>
Message-ID: <HIB_uHhARw6PDJSkKL2po_YJGQKdaiDQnscfAilzDD8=.cbb9fd34-9673-439e-9da0-4cd96a4ca1c4@github.com>

On Fri, 5 Mar 2021 17:29:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix omitted synchronized
>
> src/java.base/share/classes/java/util/Locale.java line 959:
> 
>> 957:     }
>> 958: 
>> 959:     private static Locale getDisplayLocale() {
> 
> Should this be `synchronized`?

Good catch! Fixed.

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

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

From redestad at openjdk.java.net  Fri Mar  5 18:53:29 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 18:53:29 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

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

  Fix omitted synchronized

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2845/files
  - new: https://git.openjdk.java.net/jdk/pull/2845/files/5d2f0da4..4980d2d6

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

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

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

From naoto at openjdk.java.net  Fri Mar  5 19:01:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 5 Mar 2021 19:01:09 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
Message-ID: <OAVGSb-KP7_gipVmNjpy-BxoTN_RRMe1hHid_-RMfL4=.5b6291d9-15f0-47b7-9d87-835273253152@github.com>

On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix omitted synchronized

Looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From iris at openjdk.java.net  Fri Mar  5 20:42:05 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 5 Mar 2021 20:42:05 GMT
Subject: <i18n dev> RFR: 8263091: Remove
 CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <gzdn0qEUwApKItpsxkj13U5zOxkYQwtywZockqrATFE=.ed478c2f-27ae-4352-be50-ff6322213251@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

Marked as reviewed by iris (Reviewer).

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

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

From serb at openjdk.java.net  Sat Mar  6 05:54:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Mar 2021 05:54:07 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
Message-ID: <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>

On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix omitted synchronized

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

> 944:             Locale loc = defaultDisplayLocale; // volatile read
> 945:             if (loc == null) {
> 946:                 loc = getDisplayLocale();

Just interesting how did you check that the performance difference is because of volatile read, and not because of replacing of the switch by the "if"?

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

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

From dholmes at openjdk.java.net  Sat Mar  6 12:39:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 6 Mar 2021 12:39:07 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <OAVGSb-KP7_gipVmNjpy-BxoTN_RRMe1hHid_-RMfL4=.5b6291d9-15f0-47b7-9d87-835273253152@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <OAVGSb-KP7_gipVmNjpy-BxoTN_RRMe1hHid_-RMfL4=.5b6291d9-15f0-47b7-9d87-835273253152@github.com>
Message-ID: <tslEliQLDG0knvBY5lnxXvza_L3qB2iup52LWwtsRII=.b7c89fc3-7a55-4608-a6a7-ccaaced16dff@github.com>

On Fri, 5 Mar 2021 18:58:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix omitted synchronized
>
> Looks good.

If I read the order right your benchmark findings were done before you added the missing synchronized - correct?

AFAICS the only unnecessary volatile read is on the return statement and you could fix that without doing the other refactoring. I don't see how introducing an extra method call can aid performance.

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

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

From redestad at openjdk.java.net  Sat Mar  6 13:13:04 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 6 Mar 2021 13:13:04 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <tslEliQLDG0knvBY5lnxXvza_L3qB2iup52LWwtsRII=.b7c89fc3-7a55-4608-a6a7-ccaaced16dff@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <OAVGSb-KP7_gipVmNjpy-BxoTN_RRMe1hHid_-RMfL4=.5b6291d9-15f0-47b7-9d87-835273253152@github.com>
 <tslEliQLDG0knvBY5lnxXvza_L3qB2iup52LWwtsRII=.b7c89fc3-7a55-4608-a6a7-ccaaced16dff@github.com>
Message-ID: <5Xsg7B24UVoI3bT0DNrA1G2yQINRO4i_6sgtIoxMU3k=.50404e21-bb47-45f9-a9eb-0d3a447b6a74@github.com>

On Sat, 6 Mar 2021 12:36:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If I read the order right your benchmark findings were done before you added the missing synchronized - correct?
> 
> AFAICS the only unnecessary volatile read is on the return statement and you could fix that without doing the other refactoring. I don't see how introducing an extra method call can aid performance.

Note that the score for the Display and the Format case were identical, even though one was missing synchronized. I've re-run the benchmarks after the fix and the same applies.

The methods will only ever be called during initialization, usually only once. Extracting them to separate methods helps outline initialization code from the hot path. Such outlining is a standard technique to help the JITs do the right thing, for example by ensuring you don't stumble on things like inlining thresholds.

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

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

From redestad at openjdk.java.net  Sat Mar  6 13:37:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 6 Mar 2021 13:37:07 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>
Message-ID: <Ks16r3TISrfvlzTxW1KfHtfZKIwUa2cc-PbIcO227Dk=.3626629f-276d-4449-b60c-5c2c57e09f89@github.com>

On Sat, 6 Mar 2021 05:51:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix omitted synchronized
>
> src/java.base/share/classes/java/util/Locale.java line 946:
> 
>> 944:             Locale loc = defaultDisplayLocale; // volatile read
>> 945:             if (loc == null) {
>> 946:                 loc = getDisplayLocale();
> 
> Just interesting how did you check that the performance difference is because of volatile read, and not because of replacing of the switch by the "if"?

I started out with this variant, only removing the double volatile reads:

    public static Locale getDefault(Locale.Category category) {
        // do not synchronize this method - see 4071298
        Locale loc;
        switch (category) {
        case DISPLAY:
            loc = defaultDisplayLocale;
            if (loc == null) {
                synchronized(Locale.class) {
                    loc = defaultDisplayLocale;
                    if (loc == null) {
                        loc = defaultDisplayLocale = initDefault(category);
                    }
                }
            }
            return loc;
        case FORMAT:
            loc = defaultFormatLocale;
            if (loc == null) {
                synchronized(Locale.class) {
                    loc = defaultFormatLocale;
                    if (loc == null) {
                        loc = defaultFormatLocale = initDefault(category);
                    }
                }
            }
            return loc;
        default:
            assert false: "Unknown Category";
        }
        return getDefault();
    }

Scores were the same:
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    5  10.045 ? 0.032  ns/op
LocaleDefaults.getDefaultDisplay  avgt    5  11.301 ? 0.053  ns/op
LocaleDefaults.getDefaultFormat   avgt    5  11.303 ? 0.054  ns/op

I then refactored and checked that the refactorings were performance neutral.

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

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

From serb at openjdk.java.net  Sat Mar  6 20:39:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Mar 2021 20:39:07 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <Ks16r3TISrfvlzTxW1KfHtfZKIwUa2cc-PbIcO227Dk=.3626629f-276d-4449-b60c-5c2c57e09f89@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>
 <Ks16r3TISrfvlzTxW1KfHtfZKIwUa2cc-PbIcO227Dk=.3626629f-276d-4449-b60c-5c2c57e09f89@github.com>
Message-ID: <QL50utyyHhNAF7KVp_h4rVjN1yHAKw6f6gA_AnbJA5k=.622fe80e-4e38-4974-b4cf-53cfac14016d@github.com>

On Sat, 6 Mar 2021 13:34:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 946:
>> 
>>> 944:             Locale loc = defaultDisplayLocale; // volatile read
>>> 945:             if (loc == null) {
>>> 946:                 loc = getDisplayLocale();
>> 
>> Just interesting how did you check that the performance difference is because of volatile read, and not because of replacing of the switch by the "if"?
>
> I started out with this variant, only removing the double volatile reads:
> 
>     public static Locale getDefault(Locale.Category category) {
>         // do not synchronize this method - see 4071298
>         Locale loc;
>         switch (category) {
>         case DISPLAY:
>             loc = defaultDisplayLocale;
>             if (loc == null) {
>                 synchronized(Locale.class) {
>                     loc = defaultDisplayLocale;
>                     if (loc == null) {
>                         loc = defaultDisplayLocale = initDefault(category);
>                     }
>                 }
>             }
>             return loc;
>         case FORMAT:
>             loc = defaultFormatLocale;
>             if (loc == null) {
>                 synchronized(Locale.class) {
>                     loc = defaultFormatLocale;
>                     if (loc == null) {
>                         loc = defaultFormatLocale = initDefault(category);
>                     }
>                 }
>             }
>             return loc;
>         default:
>             assert false: "Unknown Category";
>         }
>         return getDefault();
>     }
> 
> Scores were the same:
> Benchmark                         Mode  Cnt   Score   Error  Units
> LocaleDefaults.getDefault         avgt    5  10.045 ? 0.032  ns/op
> LocaleDefaults.getDefaultDisplay  avgt    5  11.301 ? 0.053  ns/op
> LocaleDefaults.getDefaultFormat   avgt    5  11.303 ? 0.054  ns/op
> 
> I then refactored and checked that the refactorings were performance neutral.

And it is faster than the final version?

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

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

From claes.redestad at oracle.com  Sat Mar  6 21:28:33 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 6 Mar 2021 21:28:33 +0000
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <QL50utyyHhNAF7KVp_h4rVjN1yHAKw6f6gA_AnbJA5k=.622fe80e-4e38-4974-b4cf-53cfac14016d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>
 <Ks16r3TISrfvlzTxW1KfHtfZKIwUa2cc-PbIcO227Dk=.3626629f-276d-4449-b60c-5c2c57e09f89@github.com>,
 <QL50utyyHhNAF7KVp_h4rVjN1yHAKw6f6gA_AnbJA5k=.622fe80e-4e38-4974-b4cf-53cfac14016d@github.com>
Message-ID: <DM5PR10MB2012E175161C83B6ADD58E83E1959@DM5PR10MB2012.namprd10.prod.outlook.com>

No, I accidentally posted numbers for an apples to oranges comparison (-t 1 vs -t 4 on the same system). The final version does not differ in performance from this version when comparing like for like.

H?mta Outlook f?r Android<https://aka.ms/ghei36>

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Sergey Bylokhov <serb at openjdk.java.net>
Sent: Saturday, March 6, 2021 9:39:07 PM
To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; i18n-dev at openjdk.java.net <i18n-dev at openjdk.java.net>
Subject: Re: RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) [v2]

On Sat, 6 Mar 2021 13:34:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 946:
>>
>>> 944:             Locale loc = defaultDisplayLocale; // volatile read
>>> 945:             if (loc == null) {
>>> 946:                 loc = getDisplayLocale();
>>
>> Just interesting how did you check that the performance difference is because of volatile read, and not because of replacing of the switch by the "if"?
>
> I started out with this variant, only removing the double volatile reads:
>
>     public static Locale getDefault(Locale.Category category) {
>         // do not synchronize this method - see 4071298
>         Locale loc;
>         switch (category) {
>         case DISPLAY:
>             loc = defaultDisplayLocale;
>             if (loc == null) {
>                 synchronized(Locale.class) {
>                     loc = defaultDisplayLocale;
>                     if (loc == null) {
>                         loc = defaultDisplayLocale = initDefault(category);
>                     }
>                 }
>             }
>             return loc;
>         case FORMAT:
>             loc = defaultFormatLocale;
>             if (loc == null) {
>                 synchronized(Locale.class) {
>                     loc = defaultFormatLocale;
>                     if (loc == null) {
>                         loc = defaultFormatLocale = initDefault(category);
>                     }
>                 }
>             }
>             return loc;
>         default:
>             assert false: "Unknown Category";
>         }
>         return getDefault();
>     }
>
> Scores were the same:
> Benchmark                         Mode  Cnt   Score   Error  Units
> LocaleDefaults.getDefault         avgt    5  10.045 ? 0.032  ns/op
> LocaleDefaults.getDefaultDisplay  avgt    5  11.301 ? 0.053  ns/op
> LocaleDefaults.getDefaultFormat   avgt    5  11.303 ? 0.054  ns/op
>
> I then refactored and checked that the refactorings were performance neutral.

And it is faster than the final version?

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

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

From serb at openjdk.java.net  Sat Mar  6 21:41:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Mar 2021 21:41:07 GMT
Subject: <i18n dev> RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
Message-ID: <uHfI25yXeG4NTArErT8v35jpIqVOQZW-aVq0xjKS374=.e27ff260-87d4-49cc-a441-3f68b6fbf602@github.com>

On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix omitted synchronized

Marked as reviewed by serb (Reviewer).

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

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

From redestad at openjdk.java.net  Mon Mar  8 10:38:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 10:38:06 GMT
Subject: <i18n dev> Integrated: 8263091: Remove
 CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <5wplMw7Bh22b4bOORpZk6sE5nFsKDaVXmn25F7soeps=.ba21d564-40f0-43a4-be1c-12b51538c1fb@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

This pull request has now been integrated.

Changeset: a0c3f242
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a0c3f242
Stats:     98 lines in 8 files changed: 1 ins; 71 del; 26 mod

8263091: Remove CharacterData.isOtherUppercase/-Lowercase

Reviewed-by: rriggs, naoto, iris

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

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

From redestad at openjdk.java.net  Mon Mar  8 11:04:10 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 11:04:10 GMT
Subject: <i18n dev> Integrated: 8263090: Avoid reading volatile fields twice
 in Locale.getDefault(Category)
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <OtH0CLSitr9LXy0Se-e1XaYUQN1Ski2D5bV2R8p5QNA=.88de834c-1ac9-46b1-8fa3-af08d722cad2@github.com>

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

This pull request has now been integrated.

Changeset: 13625beb
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/13625beb
Stats:     92 lines in 2 files changed: 72 ins; 5 del; 15 mod

8263090: Avoid reading volatile fields twice in Locale.getDefault(Category)

Reviewed-by: rriggs, naoto, serb

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

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

From pconcannon at openjdk.java.net  Mon Mar  8 18:53:19 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 8 Mar 2021 18:53:19 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
Message-ID: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>

Hi,

Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?

Kind regards,
Patrick

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

Commit messages:
 - 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable

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

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

From bpb at openjdk.java.net  Mon Mar  8 19:11:05 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 8 Mar 2021 19:11:05 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <Aqqndb9HMLoLcTYy88-v-uauh9LHTJ53dFomiiUCAEg=.4529729a-2fa8-4058-9112-1591e34d947d@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Looks good and builds cleanly: approved.

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

Marked as reviewed by bpb (Reviewer).

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

From lancea at openjdk.java.net  Mon Mar  8 19:11:04 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 8 Mar 2021 19:11:04 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <TnSlgqwnZqIqfY4VuyJn553m48F_9wvRM82kaOd7gGc=.d8d822ee-f2d6-457d-ad06-53fba9238163@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Looks good

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

Marked as reviewed by lancea (Reviewer).

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

From darcy at openjdk.java.net  Mon Mar  8 19:11:05 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Mar 2021 19:11:05 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <v78RbXoCvmvHol3MBqbv1N7fXYZnhoXWTg1zIxrlLWs=.610d5c20-6c3c-40b9-92fa-91f3f76b03ac@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by darcy (Reviewer).

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

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

From naoto at openjdk.java.net  Mon Mar  8 19:11:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 8 Mar 2021 19:11:06 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <AqEG0T-j7lNFizGqOnhUXFtzYanl7f_JJxxrlwOWELM=.23a81146-54f3-4b04-973d-72902cdac1cb@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by naoto (Reviewer).

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

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

From dfuchs at openjdk.java.net  Mon Mar  8 19:18:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 8 Mar 2021 19:18:08 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <MIMo3HnvFlOgftRF_iydqtysDP6ho_TI3YMl7tjoPXc=.ae449ceb-a9ec-4c7e-ae38-d1f2d1afc2d9@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by dfuchs (Reviewer).

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

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

From iris at openjdk.java.net  Mon Mar  8 19:18:07 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 8 Mar 2021 19:18:07 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <vDee8ZhB2ZD28i-UmdqAhNrgTJTWoSPQRT8wW-v1wG4=.8abf79b0-293f-4406-93c9-7067755bb323@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by iris (Reviewer).

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

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

From smarks at openjdk.java.net  Mon Mar  8 19:26:08 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 8 Mar 2021 19:26:08 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <hPAz8gUPr5mgSVviup8ZIJ9UpzbavgRnMpn5pYxPxHo=.409f8ff0-9b4e-4025-8685-332fe6b34ac0@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by smarks (Reviewer).

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

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

From redestad at openjdk.java.net  Mon Mar  8 20:39:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 20:39:08 GMT
Subject: <i18n dev> RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <rkddgafwznDNp7zDNXYqreQfKwFov1obgpdrxWmKFIY=.0fbd0612-b05d-455e-a8ec-044507760b4c@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by redestad (Reviewer).

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

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

From igraves at openjdk.java.net  Mon Mar  8 21:30:28 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 8 Mar 2021 21:30:28 GMT
Subject: <i18n dev> RFR: 8262351: Extra '0' in java.util.Formatter for
 '%012a' conversion with a sign character
Message-ID: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>

This fixes a zero-adding issue observed in the hex float conversion.

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

Commit messages:
 - Fixing zero-padding issue in hex float conversion

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

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

From pconcannon at openjdk.java.net  Tue Mar  9 11:12:10 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 9 Mar 2021 11:12:10 GMT
Subject: <i18n dev> Integrated: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <mzs3TTj_bmfuXGy-LDSvZWnq9UtWH4mSRsopRP5NTho=.07979890-0a63-4a16-94ea-018d268a03fb@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 0f2402d0
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f2402d0
Stats:     59 lines in 15 files changed: 0 ins; 27 del; 32 mod

8263190: Update java.io, java.math, and java.text to use instanceof pattern variable

Reviewed-by: lancea, bpb, darcy, naoto, iris, dfuchs, smarks, redestad

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

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

From bchristi at openjdk.java.net  Tue Mar  9 23:35:05 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 9 Mar 2021 23:35:05 GMT
Subject: <i18n dev> RFR: 8262351: Extra '0' in java.util.Formatter for
 '%012a' conversion with a sign character
In-Reply-To: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
Message-ID: <vuiE9zNZYhOPaxBhLo1DbKxGEjS0RzuT3LjjBHvprhI=.79c4eaa7-afc8-4a52-93cf-8191861173f5@github.com>

On Mon, 8 Mar 2021 21:25:32 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This fixes a zero-adding issue observed in the hex float conversion.

This all looks fine - just update the copyright year in Formatter.java, please.

In my personal opinion, this behavior change does not rise to the level of needing a CSR, but since it is long-standing behavior, you might double-check with Joe.

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

Changes requested by bchristi (Reviewer).

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

From igraves at openjdk.java.net  Wed Mar 10 02:31:28 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 10 Mar 2021 02:31:28 GMT
Subject: <i18n dev> RFR: 8262351: Extra '0' in java.util.Formatter for
 '%012a' conversion with a sign character [v2]
In-Reply-To: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
Message-ID: <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>

> This fixes a zero-adding issue observed in the hex float conversion.

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

  Updating Formatter copyright date

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2881/files
  - new: https://git.openjdk.java.net/jdk/pull/2881/files/441c790e..308ae14b

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

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

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

From cgo at openjdk.java.net  Wed Mar 10 09:48:06 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 10 Mar 2021 09:48:06 GMT
Subject: <i18n dev> RFR: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <WioKjap6ADDAdX_tFW3B7fwKuVaihCNA7P2yvMlZW9A=.4aa81ba1-821f-4c46-a32d-317c164c3336@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
 <zYXYhx46bm8g_dYCTXxlnrIIoOldQwc7giadIrKOxao=.22da3a8e-6349-473f-8015-a64488572469@github.com>
 <WioKjap6ADDAdX_tFW3B7fwKuVaihCNA7P2yvMlZW9A=.4aa81ba1-821f-4c46-a32d-317c164c3336@github.com>
Message-ID: <Z9deBge5p9mVlmoFiouefM5cwcsc2cmShNOf4QA0eNw=.a38221e3-1afb-4da3-9934-521a768a2abd@github.com>

On Mon, 1 Mar 2021 15:21:23 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Looks fine. This source file was a .template until a few weeks ago, probably should have fixed the indentation issues when moving it to a .java file.
>
> Thanks for the review.
> Do we need a second reviewer? If not, could you please sponsor the change?

Could a second reviewer please look at this tiny, whitespace only change and sponsor it?

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

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

From rriggs at openjdk.java.net  Wed Mar 10 14:50:08 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 10 Mar 2021 14:50:08 GMT
Subject: <i18n dev> RFR: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
Message-ID: <j3GPMUrozqWEDaXgAT3K2Gh7pM2-b7k6JRzeB5VchMQ=.ecf21307-8f49-4291-8bb8-338b1ec72bb5@github.com>

On Fri, 26 Feb 2021 17:50:19 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java

For (most) core-libs changes, only 1 reviewer is required.
However, given the broad interest, please allow time (a day or weekend) for others to take a look.

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

Marked as reviewed by rriggs (Reviewer).

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

From cgo at openjdk.java.net  Wed Mar 10 14:50:09 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 10 Mar 2021 14:50:09 GMT
Subject: <i18n dev> Integrated: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
Message-ID: <uHX-ItapkzOurcSBnXHzMKnwS-yE06rny42dFg-6_SE=.008de5d0-079f-4b87-aae3-ed62853d863b@github.com>

On Fri, 26 Feb 2021 17:50:19 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java

This pull request has now been integrated.

Changeset: c8c0234b
Author:    Christoph G?ttschkes <cgo at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c8c0234b
Stats:     13 lines in 1 file changed: 0 ins; 2 del; 11 mod

8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java

Reviewed-by: alanb, rriggs

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

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

From naoto at openjdk.java.net  Wed Mar 10 17:54:07 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Mar 2021 17:54:07 GMT
Subject: <i18n dev> RFR: 8262351: Extra '0' in java.util.Formatter for
 '%012a' conversion with a sign character [v2]
In-Reply-To: <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
 <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>
Message-ID: <bBlJx3OsyjLIiTTP0Mo-gKq8ZUb93kplOamq6yqp334=.0f0cbbc7-70c4-4cc8-82b2-2ee55d6c9c09@github.com>

On Wed, 10 Mar 2021 02:31:28 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a zero-adding issue observed in the hex float conversion.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating Formatter copyright date

Looks good to me.
BTW apart from this issue, I just noticed that in the chart in the `Formatter` class spec, there are two spaces (two NBSPs) for the `extra space` flag:
 * <tr><th scope="row" style="vertical-align:top"> <code>'&nbsp;&nbsp;'</code>
 *     <td style="vertical-align:top"> <code>'&#92;u0020'</code>
 *     <td> Requires the output to include a single extra space
 *     (<code>'&#92;u0020'</code>) for non-negative values.
 *
 *     <p> If both the {@code '+'} and <code>'&nbsp;&nbsp;'</code> flags are given
 *     then an {@link IllegalFormatFlagsException} will be thrown.
 ```
 This might be fixed sometime.

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

Marked as reviewed by naoto (Reviewer).

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

From bchristi at openjdk.java.net  Wed Mar 10 18:08:09 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 10 Mar 2021 18:08:09 GMT
Subject: <i18n dev> RFR: 8262351: Extra '0' in java.util.Formatter for
 '%012a' conversion with a sign character [v2]
In-Reply-To: <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
 <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>
Message-ID: <FH9d4SWXbKBpk7d9Qg2ASWy_oH__wrvQ1_D3ohNteoo=.b9a317a2-a8d6-445f-b708-1d51ae5c06f7@github.com>

On Wed, 10 Mar 2021 02:31:28 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a zero-adding issue observed in the hex float conversion.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating Formatter copyright date

Marked as reviewed by bchristi (Reviewer).

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

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

From igraves at openjdk.java.net  Wed Mar 10 22:50:22 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 10 Mar 2021 22:50:22 GMT
Subject: <i18n dev> Integrated: 8262351: Extra '0' in java.util.Formatter
 for '%012a' conversion with a sign character
In-Reply-To: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
Message-ID: <PD9PIl0BzLdwbu_U1G7_xwxNcxYYFSL0PqPVZ5h_TGk=.13bb0efe-a204-4eae-b858-dd8c38007e61@github.com>

On Mon, 8 Mar 2021 21:25:32 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This fixes a zero-adding issue observed in the hex float conversion.

This pull request has now been integrated.

Changeset: 6971c23a
Author:    Ian Graves <igraves at openjdk.org>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6971c23a
Stats:     56 lines in 2 files changed: 54 ins; 0 del; 2 mod

8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character

Reviewed-by: bchristi, naoto

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

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

From herrick at openjdk.java.net  Fri Mar 12 16:13:36 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 12 Mar 2021 16:13:36 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
Message-ID: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>

implementation of
JDK-8256145: JEP 398: Deprecate the Applet API for Removal

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

Commit messages:
 - 8189198: Add "forRemoval = true" to Applet API deprecations

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

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

From iris at openjdk.java.net  Fri Mar 12 18:20:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 12 Mar 2021 18:20:06 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <ZSNT5qc_BugwWIZl4x2ueqQObQFJgUQ6jzi5TZTrPhg=.57cc693b-41f8-43f2-92fb-f7c9d6b4d493@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Marked as reviewed by iris (Reviewer).

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

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

From almatvee at openjdk.java.net  Sat Mar 13 00:46:07 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 13 Mar 2021 00:46:07 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Marked as reviewed by almatvee (Committer).

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

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

From alanb at openjdk.java.net  Sun Mar 14 12:09:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 12:09:05 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
Message-ID: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>

On Sat, 13 Mar 2021 00:43:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Marked as reviewed by almatvee (Committer).

Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid adding it to some of these methods?

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

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

From github.com+7806504+liach at openjdk.java.net  Sun Mar 14 17:10:23 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Sun, 14 Mar 2021 17:10:23 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <qM2_hboz6gdDK2b146mFO0LrHSDgoji1F15qIHr23yg=.2d891359-4b5b-4e15-99fb-325c32658ff1@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

Are linked lists worse for addition even in cases where addition to array list or deque requires resize and copying? i thought that's the advantage of linked list.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:10:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:10:23 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
Message-ID: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>

The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.

jdk:tier1 and jdk:tier2 are both ok

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

Commit messages:
 - Remove remaining usages of LinkedList in java.base

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

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

From yyang at openjdk.java.net  Sun Mar 14 17:10:24 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sun, 14 Mar 2021 17:10:24 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220:

> 218:             return Collections.emptyList();
> 219:         }
> 220:         List<IOException> result = new ArrayList<>();

We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList.

Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:10:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:10:23 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <qM2_hboz6gdDK2b146mFO0LrHSDgoji1F15qIHr23yg=.2d891359-4b5b-4e15-99fb-325c32658ff1@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <qM2_hboz6gdDK2b146mFO0LrHSDgoji1F15qIHr23yg=.2d891359-4b5b-4e15-99fb-325c32658ff1@github.com>
Message-ID: <I9rVR_oIdc2Bc7QeD1smsXIU1jJFn5dQI4dzk0FeMBw=.0aeea223-cfea-4155-b960-27118210456d@github.com>

On Fri, 26 Feb 2021 15:32:57 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

> Are linked lists worse for addition even in cases where addition to array list or deque requires resize and copying? i thought that's the advantage of linked list.

As far as I know `LinkedList` is always worse than `ArrayList` and discouraged from being used.

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

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

From github.com+7806504+liach at openjdk.java.net  Sun Mar 14 17:10:24 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Sun, 14 Mar 2021 17:10:24 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
Message-ID: <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>

On Sun, 14 Mar 2021 14:58:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220:
> 
>> 218:             return Collections.emptyList();
>> 219:         }
>> 220:         List<IOException> result = new ArrayList<>();
> 
> We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList.
> 
> Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values.

If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr)

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:21:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:21:11 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
Message-ID: <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>

On Sun, 14 Mar 2021 15:02:03 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220:
>> 
>>> 218:             return Collections.emptyList();
>>> 219:         }
>>> 220:         List<IOException> result = new ArrayList<>();
>> 
>> We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList.
>> 
>> Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values.
>
> If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr)

Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes.

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

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

From alanb at openjdk.java.net  Sun Mar 14 17:29:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 17:29:06 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
 <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
Message-ID: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>

On Sun, 14 Mar 2021 17:18:11 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr)
>
> Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes.

Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 18:24:17 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 18:24:17 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
 <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
 <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
Message-ID: <FnmswLcLaHsAq8Gl6qOAFd2fFFQUaGp14wDcjsmfOog=.6eb4e680-d64c-4774-9bf2-76b7806d48ff@github.com>

On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes.
>
> Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here.

@AlanBateman so is it ok to keep `ArrayLists`?

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

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

From iignatyev at openjdk.java.net  Mon Mar 15 05:03:20 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 15 Mar 2021 05:03:20 GMT
Subject: <i18n dev> RFR: 8263556: remove `@modules java.base` from tests
Message-ID: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>

Hi all,

could you please review this trivial cleanup?
from JBS:

> jtreg `@modules X` directive does two things: 
>  - exclude a test from execution if JDK under test doesn't have module X 
>  - if JDK under test has module X, make sure it's resolved 
> 
> both these things have no sense for `java.base` module as it's always available and is always resolved.


Thanks,
-- Igor

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

Commit messages:
 - update copyright year
 - 8263556: remove `@modules java.base` from tests

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

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

From alanb at openjdk.java.net  Mon Mar 15 06:59:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Mar 2021 06:59:07 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
 <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
 <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
Message-ID: <VSPKLm1HjhCkd_WmlFJCikNyedxejJnBZ0JOwUxb87k=.35ea99d2-b3d4-4203-b9f2-2a2548262dcb@github.com>

On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes.
>
> Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here.

> @AlanBateman so is it ok to keep `ArrayLists`?

One thing to look out for is usages of 2-arg add method that inserts at a specific position. This shouldn't be a concern in URLClassPath.closeLoaders (assuming this is this usage where the question arises).

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

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

From dcubed at openjdk.java.net  Mon Mar 15 13:33:09 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 15 Mar 2021 13:33:09 GMT
Subject: <i18n dev> RFR: 8263556: remove `@modules java.base` from tests
In-Reply-To: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
Message-ID: <vt_ig8proE47pyW_GO65iNSBJze1J1lth7funqC5hLY=.767f73f0-c662-40de-961d-8f6e542abdff@github.com>

On Sat, 13 Mar 2021 20:26:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup?
> from JBS:
> 
>> jtreg `@modules X` directive does two things: 
>>  - exclude a test from execution if JDK under test doesn't have module X 
>>  - if JDK under test has module X, make sure it's resolved 
>> 
>> both these things have no sense for `java.base` module as it's always available and is always resolved.
> 
> 
> Thanks,
> -- Igor

Thumbs up.

I agree that this is a trivial change.

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

Marked as reviewed by dcubed (Reviewer).

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

From naoto at openjdk.java.net  Mon Mar 15 16:21:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 15 Mar 2021 16:21:08 GMT
Subject: <i18n dev> RFR: 8263556: remove `@modules java.base` from tests
In-Reply-To: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
Message-ID: <HyuCdO-YEWWAPBA0aMaYStTr9sbkPq4CLtDhDDKFOqo=.d48cb16a-9c44-43bc-9982-8caaa5cb77ea@github.com>

On Sat, 13 Mar 2021 20:26:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup?
> from JBS:
> 
>> jtreg `@modules X` directive does two things: 
>>  - exclude a test from execution if JDK under test doesn't have module X 
>>  - if JDK under test has module X, make sure it's resolved 
>> 
>> both these things have no sense for `java.base` module as it's always available and is always resolved.
> 
> 
> Thanks,
> -- Igor

Marked as reviewed by naoto (Reviewer).

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

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

From iris at openjdk.java.net  Mon Mar 15 16:28:08 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 15 Mar 2021 16:28:08 GMT
Subject: <i18n dev> RFR: 8263556: remove `@modules java.base` from tests
In-Reply-To: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
Message-ID: <THNM-XilKIXLEJ5ppuFH13GRabVhgx82vU7VYnNygJA=.70eb2d24-6ab2-4e0c-ac7f-2f1776513d97@github.com>

On Sat, 13 Mar 2021 20:26:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup?
> from JBS:
> 
>> jtreg `@modules X` directive does two things: 
>>  - exclude a test from execution if JDK under test doesn't have module X 
>>  - if JDK under test has module X, make sure it's resolved 
>> 
>> both these things have no sense for `java.base` module as it's always available and is always resolved.
> 
> 
> Thanks,
> -- Igor

Marked as reviewed by iris (Reviewer).

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

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

From iignatyev at openjdk.java.net  Mon Mar 15 17:08:09 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 15 Mar 2021 17:08:09 GMT
Subject: <i18n dev> RFR: 8263556: remove `@modules java.base` from tests
In-Reply-To: <THNM-XilKIXLEJ5ppuFH13GRabVhgx82vU7VYnNygJA=.70eb2d24-6ab2-4e0c-ac7f-2f1776513d97@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
 <THNM-XilKIXLEJ5ppuFH13GRabVhgx82vU7VYnNygJA=.70eb2d24-6ab2-4e0c-ac7f-2f1776513d97@github.com>
Message-ID: <W4rj4p-NDWVUTm1bihvZuOXxeH550Oks3UZbs7G5Am0=.db3e6087-440d-4da4-8b21-a55780dfe190@github.com>

On Mon, 15 Mar 2021 16:25:48 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this trivial cleanup?
>> from JBS:
>> 
>>> jtreg `@modules X` directive does two things: 
>>>  - exclude a test from execution if JDK under test doesn't have module X 
>>>  - if JDK under test has module X, make sure it's resolved 
>>> 
>>> both these things have no sense for `java.base` module as it's always available and is always resolved.
>> 
>> 
>> Thanks,
>> -- Igor
>
> Marked as reviewed by iris (Reviewer).

Iris, Naoto, Dan, thank you for your reviews!

-- Igor

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

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

From iignatyev at openjdk.java.net  Mon Mar 15 17:08:10 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 15 Mar 2021 17:08:10 GMT
Subject: <i18n dev> Integrated: 8263556: remove `@modules java.base` from
 tests
In-Reply-To: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
Message-ID: <47c19e0cAuCEtsxE3PtvwXJdmbdvqPSj7oZglqg5c_E=.6d397d21-b62d-4c77-a6fb-7d682b983870@github.com>

On Sat, 13 Mar 2021 20:26:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup?
> from JBS:
> 
>> jtreg `@modules X` directive does two things: 
>>  - exclude a test from execution if JDK under test doesn't have module X 
>>  - if JDK under test has module X, make sure it's resolved 
>> 
>> both these things have no sense for `java.base` module as it's always available and is always resolved.
> 
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: d825198e
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d825198e
Stats:     21 lines in 13 files changed: 0 ins; 13 del; 8 mod

8263556: remove `@modules java.base` from tests

Reviewed-by: dcubed, naoto, iris

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

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

From redestad at openjdk.java.net  Tue Mar 16 19:48:19 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Mar 2021 19:48:19 GMT
Subject: <i18n dev> RFR: 8263677: Improve
 Character.isLowerCase/isUpperCase lookups
In-Reply-To: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
References: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
Message-ID: <3m5QMvNjzynNX2VEaHMT6Ro9nre6XqDu-uHbPv0LITk=.9e5122ae-e33c-4451-8f25-13fe1cca2f0c@github.com>

On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.
> 
> I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.
> 
> Testing: tier1-3

Baseline:
Benchmark               (codePoint)  Mode  Cnt   Score   Error  Units
Characters.isLowerCase            9  avgt    5  13.809 ? 0.032  ns/op
Characters.isLowerCase           65  avgt    5  13.811 ? 0.052  ns/op
Characters.isLowerCase           97  avgt    5  12.552 ? 0.057  ns/op
Characters.isLowerCase          128  avgt    5  13.823 ? 0.076  ns/op
Characters.isLowerCase          170  avgt    5  13.811 ? 0.066  ns/op
Characters.isLowerCase          223  avgt    5  12.556 ? 0.058  ns/op
Characters.isLowerCase          410  avgt    5  19.466 ? 0.104  ns/op
Characters.isLowerCase          430  avgt    5  20.718 ? 0.100  ns/op
Characters.isUpperCase            9  avgt    5  12.556 ? 0.056  ns/op
Characters.isUpperCase           65  avgt    5  12.559 ? 0.067  ns/op
Characters.isUpperCase           97  avgt    5  12.555 ? 0.055  ns/op
Characters.isUpperCase          128  avgt    5  12.559 ? 0.060  ns/op
Characters.isUpperCase          170  avgt    5  12.556 ? 0.036  ns/op
Characters.isUpperCase          223  avgt    5  12.554 ? 0.055  ns/op
Characters.isUpperCase          410  avgt    5  20.722 ? 0.129  ns/op
Characters.isUpperCase          430  avgt    5  19.459 ? 0.091  ns/op

Patch:
Benchmark               (codePoint)  Mode  Cnt   Score   Error  Units
Characters.isLowerCase            9  avgt    5  12.556 ? 0.035  ns/op
Characters.isLowerCase           65  avgt    5  12.562 ? 0.073  ns/op
Characters.isLowerCase           97  avgt    5  12.551 ? 0.062  ns/op
Characters.isLowerCase          128  avgt    5  12.553 ? 0.039  ns/op
Characters.isLowerCase          170  avgt    5  12.554 ? 0.051  ns/op
Characters.isLowerCase          223  avgt    5  12.552 ? 0.035  ns/op
Characters.isLowerCase          410  avgt    5  18.833 ? 0.068  ns/op
Characters.isLowerCase          430  avgt    5  18.832 ? 0.074  ns/op
Characters.isUpperCase            9  avgt    5  12.555 ? 0.050  ns/op
Characters.isUpperCase           65  avgt    5  12.557 ? 0.041  ns/op
Characters.isUpperCase           97  avgt    5  12.554 ? 0.056  ns/op
Characters.isUpperCase          128  avgt    5  12.554 ? 0.055  ns/op
Characters.isUpperCase          170  avgt    5  12.555 ? 0.054  ns/op
Characters.isUpperCase          223  avgt    5  12.553 ? 0.036  ns/op
Characters.isUpperCase          410  avgt    5  18.831 ? 0.099  ns/op
Characters.isUpperCase          430  avgt    5  18.826 ? 0.047  ns/op

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

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

From redestad at openjdk.java.net  Tue Mar 16 19:48:18 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Mar 2021 19:48:18 GMT
Subject: <i18n dev> RFR: 8263677: Improve Character.isLowerCase/isUpperCase
 lookups
Message-ID: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>

This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.

I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.

Testing: tier1-3

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

Commit messages:
 - Merge branch 'master' into character_case
 - Cleanups and modernizations
 - Fix lookup in 00, 01, 0E planes
 - Widen the range of codepoints tested by Characters micro
 - Improve Character.isLowerCase/isUpperCase lookups

Changes: https://git.openjdk.java.net/jdk/pull/3028/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3028&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263677
  Stats: 261 lines in 8 files changed: 13 ins; 129 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3028.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3028/head:pull/3028

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

From erikj at openjdk.java.net  Tue Mar 16 20:02:14 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 16 Mar 2021 20:02:14 GMT
Subject: <i18n dev> RFR: 8263677: Improve
 Character.isLowerCase/isUpperCase lookups
In-Reply-To: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
References: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
Message-ID: <s10e4RYLOXthT6q97nvu2NLYlIyZau8tf9EX0z5llrM=.7b457ef6-ddbb-4bf1-96ba-49c01a2abe94@github.com>

On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.
> 
> I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.
> 
> Testing: tier1-3

Looks good from build point of view. I like the code cleanups.

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

Marked as reviewed by erikj (Reviewer).

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

From rriggs at openjdk.java.net  Tue Mar 16 20:23:10 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 16 Mar 2021 20:23:10 GMT
Subject: <i18n dev> RFR: 8263677: Improve
 Character.isLowerCase/isUpperCase lookups
In-Reply-To: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
References: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
Message-ID: <zq1UfkGQ0koqOKVeLxw1YEZi3OUiSkX02Dbsd-z4biw=.d3c44434-8943-4ca3-b191-f12cf8bc640e@github.com>

On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.
> 
> I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.
> 
> Testing: tier1-3

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 310:

> 308:     {
> 309:         long[] result;
> 310:         if (bLatin1) {

perhaps shorten to:
final long[] result = new long[bLatin1 ? 256 : 1 << 16];

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 652:

> 650:             // There is no block just like it already, so add it to
> 651:             // the buffer and put its index into the new map.
> 652:             if (m >= 0) System.arraycopy(map, i, buffer, ptr, m);

If m == 0, you could skip the arraycopy.

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 659:

> 657:         // so create a new array and copy data from the temporary buffer.
> 658:         long[] newdata = new long[ptr];
> 659:         if (ptr >= 0) System.arraycopy(buffer, 0, newdata, 0, ptr);

ditto, if ptr == 0, skip the arraycopy

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1588:

> 1586:         StringBuffer desc = new StringBuffer("java GenerateCharacter");
> 1587:         for (String arg : args) {
> 1588:             desc.append(" " + arg);

Avoid string concat:  
   desc.append(' ').append(arg);

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

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

From redestad at openjdk.java.net  Tue Mar 16 21:02:28 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Mar 2021 21:02:28 GMT
Subject: <i18n dev> RFR: 8263677: Improve
 Character.isLowerCase/isUpperCase lookups [v2]
In-Reply-To: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
References: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
Message-ID: <Tkpcm4rEPpd_zZL_OBfnLmv-GWRzwfnArQPEQyyzvBY=.c9152d1b-ab0b-4186-b19d-c79975b5e8bf@github.com>

> This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.
> 
> I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.
> 
> Testing: tier1-3

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

  Roger review + additional cleanups

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3028/files
  - new: https://git.openjdk.java.net/jdk/pull/3028/files/5dc70a95..5698b88c

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

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

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

From ihse at openjdk.java.net  Tue Mar 16 21:32:09 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 16 Mar 2021 21:32:09 GMT
Subject: <i18n dev> RFR: 8263677: Improve
 Character.isLowerCase/isUpperCase lookups [v2]
In-Reply-To: <Tkpcm4rEPpd_zZL_OBfnLmv-GWRzwfnArQPEQyyzvBY=.c9152d1b-ab0b-4186-b19d-c79975b5e8bf@github.com>
References: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
 <Tkpcm4rEPpd_zZL_OBfnLmv-GWRzwfnArQPEQyyzvBY=.c9152d1b-ab0b-4186-b19d-c79975b5e8bf@github.com>
Message-ID: <ex_6VLgs_QGMZBv8wZjRzr8u21BplcDFZn567P25xYU=.52da87f0-c017-4b79-996f-b40f0848e453@github.com>

On Tue, 16 Mar 2021 21:02:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.
>> 
>> I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger review + additional cleanups

Marked as reviewed by ihse (Reviewer).

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

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

From naoto at openjdk.java.net  Tue Mar 16 21:37:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 16 Mar 2021 21:37:08 GMT
Subject: <i18n dev> RFR: 8263677: Improve
 Character.isLowerCase/isUpperCase lookups [v2]
In-Reply-To: <Tkpcm4rEPpd_zZL_OBfnLmv-GWRzwfnArQPEQyyzvBY=.c9152d1b-ab0b-4186-b19d-c79975b5e8bf@github.com>
References: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
 <Tkpcm4rEPpd_zZL_OBfnLmv-GWRzwfnArQPEQyyzvBY=.c9152d1b-ab0b-4186-b19d-c79975b5e8bf@github.com>
Message-ID: <XQb4fOXWu4LCtFE4PmtkrXeUEIaEr41ZgAZs3EmylYs=.9aaa16ab-fcbf-4ef5-87c6-17c045ded492@github.com>

On Tue, 16 Mar 2021 21:02:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.
>> 
>> I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger review + additional cleanups

Marked as reviewed by naoto (Reviewer).

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

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

From github.com+76791+alblue at openjdk.java.net  Wed Mar 17 12:17:00 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 17 Mar 2021 12:17:00 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in java.base
Message-ID: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>

Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.

This fixes the issues in the `java.base` package for ease of reviewing.

https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

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

Commit messages:
 - 8263658: Use the blessed modifier order in java.base

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

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

From shade at openjdk.java.net  Wed Mar 17 12:17:00 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 17 Mar 2021 12:17:00 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <YHFo0zT_eq_LraNsD7z8BqjL1xU-VUdlS0Gt2wBmOxc=.e1da1bb5-33b4-4e10-bd7f-68c85761a20b@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Please change the synopsis to "8263658: Use the blessed modifier order in java.base" to get this PR hooked properly to the new bug. Also configure the run the testing, see "Pre-submit test status" in "Checks".

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

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

From rriggs at openjdk.java.net  Wed Mar 17 13:31:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 13:31:50 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <VTJtQ5OoCu2esV2ccxoFEYezFV_MK59j8F_JnbsBcqk=.ac951e53-5c44-4083-b662-7e4c92bd8bb5@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Marked as reviewed by rriggs (Reviewer).

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

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

From rriggs at openjdk.java.net  Wed Mar 17 13:53:54 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 13:53:54 GMT
Subject: <i18n dev> RFR: 8263677: Improve
 Character.isLowerCase/isUpperCase lookups [v2]
In-Reply-To: <Tkpcm4rEPpd_zZL_OBfnLmv-GWRzwfnArQPEQyyzvBY=.c9152d1b-ab0b-4186-b19d-c79975b5e8bf@github.com>
References: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
 <Tkpcm4rEPpd_zZL_OBfnLmv-GWRzwfnArQPEQyyzvBY=.c9152d1b-ab0b-4186-b19d-c79975b5e8bf@github.com>
Message-ID: <JjyU3MuAxNNXn7E8f_AaBeOaS7njVrxsYzWGYqJ7LRU=.50965c37-d1dc-4fd8-aabc-631d4e69adf5@github.com>

On Tue, 16 Mar 2021 21:02:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.
>> 
>> I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.
>> 
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger review + additional cleanups

Marked as reviewed by rriggs (Reviewer).

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

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

From redestad at openjdk.java.net  Wed Mar 17 15:25:50 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Mar 2021 15:25:50 GMT
Subject: <i18n dev> Integrated: 8263677: Improve
 Character.isLowerCase/isUpperCase lookups
In-Reply-To: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
References: <3GEMn8qlFKxnsF8qfTB_fz-m6JfuAPWXXCWuow1x8TM=.e9241d21-26d9-4174-89cf-e95cae543046@github.com>
Message-ID: <k9Xgz_qX-ZlJRpiM6CgXRVZzFQiCwIlpa-EqVLHQIFk=.cd8c928e-12e9-411a-8fc5-fea684e9332a@github.com>

On Tue, 16 Mar 2021 12:51:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch changes the otherLowercase / otherUppercase bits to be set if either the codepoint is of type LOWERCASE_LETTER and UPPERCASE_LETTER, or the Unicode Other_Lowercase / Other_Uppercase property is set. This simplifies the lookup in Character.isLowerCase/isUpperCase to a single table lookup, which appears to be healthy for performance.
> 
> I also took the opportunity to clean up the somewhat dated GenerateCharacter utility class.
> 
> Testing: tier1-3

This pull request has now been integrated.

Changeset: e152cc03
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e152cc03
Stats:     283 lines in 8 files changed: 15 ins; 137 del; 131 mod

8263677: Improve Character.isLowerCase/isUpperCase lookups

Reviewed-by: erikj, ihse, naoto, rriggs

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

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

From herrick at openjdk.java.net  Wed Mar 17 15:35:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 15:35:49 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
Message-ID: <4WfIqOQTCLxtbCQnD2xn4Doku9I1K5cnZ3FOv_JfeJQ=.09c24289-7e79-4592-9043-36b3b790701f@github.com>

On Sun, 14 Mar 2021 12:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> the

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

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

From herrick at openjdk.java.net  Wed Mar 17 15:35:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 15:35:49 GMT
Subject: <i18n dev> Withdrawn: 8189198: Add "forRemoval = true" to Applet
 API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <HTWVY7MhXEo0XsFT0RVMz53wTcGRnOg8SwGNghVgDtk=.7c738703-a42a-4f3e-9466-df2cf05cf2d0@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

This pull request has been closed without being integrated.

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

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

From herrick at openjdk.java.net  Wed Mar 17 16:46:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 16:46:49 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
Message-ID: <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>

On Sun, 14 Mar 2021 12:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid adding it to some of these methods?

in all cases either:
 - the class or method itself is being deprecated
 - the method takes a deprecated arg .
 - there is no local variable involved, such as testing if something  is an instanceOf a class being deprecated, or calling a deprecated method.

I cannot find any instances where the scope can be narrowed

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

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

From alanb at openjdk.java.net  Wed Mar 17 19:05:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Mar 2021 19:05:52 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
Message-ID: <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>

On Wed, 17 Mar 2021 16:44:19 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> I cannot find any instances where the scope can be narrowed

Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?

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

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

From herrick at openjdk.java.net  Wed Mar 17 20:35:54 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 20:35:54 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
 <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
Message-ID: <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>

On Wed, 17 Mar 2021 19:02:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> > I cannot find any instances where the scope can be narrowed
> 
> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?

These have the code pattern such as: 
} else if (c instanceof JApplet) {
putting '@SuppressWarnings("removal")' before the declaration of 'c' does not help, because the code is not an assignment to 'c'

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

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

From redestad at openjdk.java.net  Thu Mar 18 14:53:45 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 14:53:45 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Marked as reviewed by redestad (Reviewer).

src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52:

> 50:      * from server.
> 51:      */
> 52:     //public static final int DOMAIN_UNMATCH = 3;

Maybe this one ought to be removed instead?

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

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

From shade at openjdk.java.net  Thu Mar 18 15:10:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 18 Mar 2021 15:10:38 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
Message-ID: <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>

On Wed, 17 Mar 2021 12:31:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
>> 
>> This fixes the issues in the `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52:
> 
>> 50:      * from server.
>> 51:      */
>> 52:     //public static final int DOMAIN_UNMATCH = 3;
> 
> Maybe this one ought to be removed instead?

Yeah, I agree.

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

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

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 16:47:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 16:47:40 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>
Message-ID: <PCW2pC2AmLfkdrDob6soWkFfcRVeWlIBjfZyN6tadAs=.dc680f4c-c7d3-47b3-94ec-426ae6e78a36@github.com>

On Thu, 18 Mar 2021 15:08:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52:
>> 
>>> 50:      * from server.
>>> 51:      */
>>> 52:     //public static final int DOMAIN_UNMATCH = 3;
>> 
>> Maybe this one ought to be removed instead?
>
> Yeah, I agree.

Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes.

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

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

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 16:53:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 16:53:40 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
Message-ID: <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>

On Thu, 18 Mar 2021 14:50:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
>> 
>> This fixes the issues in the `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> Marked as reviewed by redestad (Reviewer).

If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?

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

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

From redestad at openjdk.java.net  Thu Mar 18 16:53:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 16:53:40 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <PCW2pC2AmLfkdrDob6soWkFfcRVeWlIBjfZyN6tadAs=.dc680f4c-c7d3-47b3-94ec-426ae6e78a36@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>
 <PCW2pC2AmLfkdrDob6soWkFfcRVeWlIBjfZyN6tadAs=.dc680f4c-c7d3-47b3-94ec-426ae6e78a36@github.com>
Message-ID: <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com>

On Thu, 18 Mar 2021 16:42:39 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Yeah, I agree.
>
> Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes.

There's another constant with value 3 defined, so I think this is just some left-over. 

If you prefer separating out the removal to another RFE I'd remove this particular change from this PR.

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

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

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 17:02:57 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 17:02:57 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base [v2]
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com>

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

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

  8263658: Use the blessed modifier order in java.base

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2993/files
  - new: https://git.openjdk.java.net/jdk/pull/2993/files/470f7066..86aa9a34

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

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

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

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 17:02:57 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 17:02:57 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base [v2]
In-Reply-To: <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>
 <PCW2pC2AmLfkdrDob6soWkFfcRVeWlIBjfZyN6tadAs=.dc680f4c-c7d3-47b3-94ec-426ae6e78a36@github.com>
 <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com>
Message-ID: <3uerJX_48Cm81fytVhYU__vSyWnHNBkBkjVyhvkwAIw=.0d4c85de-ff4e-4d10-883c-156ebc9b13a3@github.com>

On Thu, 18 Mar 2021 16:50:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes.
>
> There's another constant with value 3 defined, so I think this is just some left-over. 
> 
> If you prefer separating out the removal to another RFE I'd remove this particular change from this PR.

Filed #3076 for the removal and updated this PR without it

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

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

From redestad at openjdk.java.net  Thu Mar 18 17:08:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 17:08:39 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base [v2]
In-Reply-To: <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
Message-ID: <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com>

On Thu, 18 Mar 2021 16:51:35 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?

Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules.

A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts.

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

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

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 17:08:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 17:08:40 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base [v2]
In-Reply-To: <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
 <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com>
Message-ID: <iixvb7a-v-TTS82u63lXVg0sYDy7eEdFuUg0awEBBhw=.7f604fe7-3a13-4bf1-8e23-407d869bc709@github.com>

On Thu, 18 Mar 2021 17:03:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?
>
>> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?
> 
> Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules.
> 
> A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts.

I'm happy to either widen the scope of this PR or to submit multiple but I have to rely on the kindness of strangers to create appropriate bugs in the system. On the one hand I don't want to cause a lot of noise but  on the other having smaller independent commits (particularly if they hit a lot of files/modules) seems like a more sensible plan to me.

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

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

From redestad at openjdk.java.net  Thu Mar 18 17:15:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 17:15:38 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base [v2]
In-Reply-To: <iixvb7a-v-TTS82u63lXVg0sYDy7eEdFuUg0awEBBhw=.7f604fe7-3a13-4bf1-8e23-407d869bc709@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
 <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com>
 <iixvb7a-v-TTS82u63lXVg0sYDy7eEdFuUg0awEBBhw=.7f604fe7-3a13-4bf1-8e23-407d869bc709@github.com>
Message-ID: <VNNCEP8MHTTbceAlsIr8bc7TEXn8v4YFgsxmuM-s-EQ=.2649f7d8-d081-4a76-8529-1fe3e52bbbb9@github.com>

On Thu, 18 Mar 2021 17:06:04 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>>> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?
>> 
>> Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules.
>> 
>> A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts.
>
> I'm happy to either widen the scope of this PR or to submit multiple but I have to rely on the kindness of strangers to create appropriate bugs in the system. On the one hand I don't want to cause a lot of noise but  on the other having smaller independent commits (particularly if they hit a lot of files/modules) seems like a more sensible plan to me.

There's some extra churn in splitting it up, sure, but different modules are often maintained by different people so getting changes that span the entire JDK reviewed might actually take you longer.  YMMV. I can assist creating RFEs.

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

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

From redestad at openjdk.java.net  Thu Mar 18 17:51:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 17:51:40 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base [v2]
In-Reply-To: <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com>
Message-ID: <dNc9yaucF2HGdAruXlcTdHs0It9pyZRe4GZmcxA0NMQ=.a3b9f61e-e26b-49c8-83a4-ae6fda1f375e@github.com>

On Thu, 18 Mar 2021 17:02:57 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
>> 
>> This fixes the issues in the `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> Alex Blewitt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by redestad (Reviewer).

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:09:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:09:40 GMT
Subject: <i18n dev> Integrated: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <8mDze9YmhXvmW4gbfQLalR266LqHkNACv0ggx-z8d9E=.b33aab37-39ce-4e3c-85c4-8f5a6ebc53d7@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

This pull request has now been integrated.

Changeset: b49c5893
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b49c5893
Stats:     139 lines in 28 files changed: 0 ins; 0 del; 139 mod

8263658: Use the blessed modifier order in java.base

Reviewed-by: rriggs, redestad

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

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

From naoto at openjdk.java.net  Fri Mar 19 18:02:47 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 18:02:47 GMT
Subject: <i18n dev> RFR: 8263890: Broken links to Unicode.org
Message-ID: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>

Fixed several broken links to Unicode.org.

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

Commit messages:
 - 8263890: Broken links to Unicode.org

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

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

From redestad at openjdk.java.net  Fri Mar 19 18:10:43 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:10:43 GMT
Subject: <i18n dev> RFR: 8263890: Broken links to Unicode.org
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <XmFHKPQipAOnCL-2AIp3T8L2xItuaRevAETKB_l_5I4=.920f1d21-37d3-4cf8-accb-ccb6b09585ef@github.com>

On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed several broken links to Unicode.org.

Marked as reviewed by redestad (Reviewer).

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 18:28:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 18:28:46 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in java.base
Message-ID: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>

Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

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

Commit messages:
 - 8263658: Use the blessed modifier order in java.base

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

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

From naoto at openjdk.java.net  Fri Mar 19 18:33:38 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 18:33:38 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
Message-ID: <WeJYWJVAt79HmlePFH6QIxKGhhuoxh1U4pKMzeJ-YP8=.5ba7a4f6-ce72-4291-a2ed-5f71535a9de5@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by naoto (Reviewer).

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

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

From redestad at openjdk.java.net  Fri Mar 19 18:36:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:36:40 GMT
Subject: <i18n dev> RFR: 8263658: Use the blessed modifier order in
 java.base
In-Reply-To: <WeJYWJVAt79HmlePFH6QIxKGhhuoxh1U4pKMzeJ-YP8=.5ba7a4f6-ce72-4291-a2ed-5f71535a9de5@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
 <WeJYWJVAt79HmlePFH6QIxKGhhuoxh1U4pKMzeJ-YP8=.5ba7a4f6-ce72-4291-a2ed-5f71535a9de5@github.com>
Message-ID: <WxErbi_jgld4GOO8LNVX2qglJgfmpjOQDg1ImAIS-vk=.e259caa7-7060-489a-a6d2-9a8a3fa9aebb@github.com>

On Fri, 19 Mar 2021 18:31:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.
>
> Marked as reviewed by naoto (Reviewer).

Can't reuse the bug IDs, sadly. Filed https://bugs.openjdk.java.net/browse/JDK-8263892 (note the new summary name to disambiguate)

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

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

From joehw at openjdk.java.net  Fri Mar 19 18:46:41 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 19 Mar 2021 18:46:41 GMT
Subject: <i18n dev> RFR: 8263890: Broken links to Unicode.org
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <RyyqvQ-TP0Rc31L8srfPTP0C5s26rqV-xTwCvCxO6ZA=.d007a872-42ae-4bba-9992-08c56eae306c@github.com>

On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed several broken links to Unicode.org.

Some minor comments.

src/java.base/share/classes/java/text/Collator.java line 211:

> 209:      * FULL_DECOMPOSITION corresponds to Normalization Form KD as
> 210:      * described in
> 211:      * <a href="http://www.unicode.org/reports/tr15/tr15-23.html">Unicode

While the previous "Unicode Technical Report #15" was in http://unicode.org/reports/tr15/tr15-15.html, by tr15-23 it was "approved by the Unicode Technical Committee as a Unicode Standard Annex". Do we want to change the title to "Unicode Standard Annex #15"? Also, is Collator stuck with a particular revision (e.g. 23) or do we refer to the latest, e.g. "http://www.unicode.org/reports/tr15/"?

src/java.base/share/classes/jdk/internal/icu/text/BidiLine.java line 50:

> 48:      * which has already been processed according to
> 49:      * the Unicode 3.0 Bidi algorithm as defined in
> 50:      * http://www.unicode.org/reports/tr9/ , version 13,

Previous references provided links e.g. "<a href="http://www.unicode.org/unicode/reports/tr9/">Unicode Standard Annex #9</a>" instead of URL.

src/java.base/share/classes/jdk/internal/icu/text/Normalizer2.java line 46:

> 44:  * a string is already normalized.
> 45:  * The most commonly used normalization forms are those defined in
> 46:  * http://www.unicode.org/reports/tr15/

Same as above.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java line 476:

> 474:  * <h3>TODO</h3>
> 475:  * <ul>
> 476:  *   <li><a href="http://www.unicode.org/reports/tr18/">Unicode Regular Expression Guidelines</a>

Just a note that the references had been report numbers, e.g. Report/Annex #15, while this one the Title (by the way, the official title was "Unicode Regular Expressions"). The only exception seems to be the one in NormalizerBase.java where it referred to the number + title.

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

Marked as reviewed by joehw (Reviewer).

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

From iris at openjdk.java.net  Fri Mar 19 18:49:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 19 Mar 2021 18:49:39 GMT
Subject: <i18n dev> RFR: 8263890: Broken links to Unicode.org
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <8LHQ2ODp9B_zd5EYnCVgGDQRFE_OiA-xrMUkMO7D2lA=.62332eea-65a9-452d-aa3a-cc8eaeaff93a@github.com>

On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed several broken links to Unicode.org.

Marked as reviewed by iris (Reviewer).

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

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

From iris at openjdk.java.net  Fri Mar 19 20:04:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 19 Mar 2021 20:04:39 GMT
Subject: <i18n dev> RFR: 8263892: More modifier order fixes in java.base
In-Reply-To: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
Message-ID: <WW8Uiz7VWT63fRllDsyyOIM_jcce7igUiZ9GZ2WVVH8=.46a4ff02-0c9e-49ca-bf13-dc7de32c497b@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by iris (Reviewer).

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

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

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 21:09:42 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 21:09:42 GMT
Subject: <i18n dev> Integrated: 8263892: More modifier order fixes in
 java.base
In-Reply-To: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
Message-ID: <3DMY9iQ9ES67nDcNnpKUWpfQ_3HwoQ-7LSkJ-hZCNtA=.027dd909-930c-4b61-bee3-62345ac73c25@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

This pull request has now been integrated.

Changeset: 77ebc110
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77ebc110
Stats:     19 lines in 5 files changed: 0 ins; 0 del; 19 mod

8263892: More modifier order fixes in java.base

Reviewed-by: naoto, iris, redestad

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

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

From redestad at openjdk.java.net  Fri Mar 19 21:09:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 21:09:41 GMT
Subject: <i18n dev> RFR: 8263892: More modifier order fixes in java.base
In-Reply-To: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
Message-ID: <ju3pqamjIIrrIhgVETmEzWBlXQgibYhLCkHqJEDurGc=.3bc3ed82-b34d-48ae-835d-c7126f9fd165@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by redestad (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Mar 19 21:23:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 21:23:03 GMT
Subject: <i18n dev> RFR: 8263890: Broken links to Unicode.org [v2]
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <0jlj0Svj0A2dteB8XDfJm4194KRtyWpoOx5Y4r-Y1ls=.fb544b73-3342-48fa-b9e1-a97dbb58267a@github.com>

> Fixed several broken links to Unicode.org.

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

  Addressed review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3093/files
  - new: https://git.openjdk.java.net/jdk/pull/3093/files/2b32b86a..37093a4d

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

  Stats: 24 lines in 6 files changed: 4 ins; 0 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3093.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3093/head:pull/3093

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

From naoto at openjdk.java.net  Fri Mar 19 21:25:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 21:25:40 GMT
Subject: <i18n dev> RFR: 8263890: Broken links to Unicode.org [v2]
In-Reply-To: <RyyqvQ-TP0Rc31L8srfPTP0C5s26rqV-xTwCvCxO6ZA=.d007a872-42ae-4bba-9992-08c56eae306c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
 <RyyqvQ-TP0Rc31L8srfPTP0C5s26rqV-xTwCvCxO6ZA=.d007a872-42ae-4bba-9992-08c56eae306c@github.com>
Message-ID: <nmF3Hn8yJhlcdffba40xZNyaiLG_z5M0CIePDiM7CBM=.66102792-3935-4fe5-b0b4-04f14a0e07e7@github.com>

On Fri, 19 Mar 2021 18:43:30 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Some minor comments.

Thanks, Joe. Addressed them as suggested.

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

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

From joehw at openjdk.java.net  Fri Mar 19 21:33:45 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 19 Mar 2021 21:33:45 GMT
Subject: <i18n dev> RFR: 8263890: Broken links to Unicode.org [v2]
In-Reply-To: <0jlj0Svj0A2dteB8XDfJm4194KRtyWpoOx5Y4r-Y1ls=.fb544b73-3342-48fa-b9e1-a97dbb58267a@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
 <0jlj0Svj0A2dteB8XDfJm4194KRtyWpoOx5Y4r-Y1ls=.fb544b73-3342-48fa-b9e1-a97dbb58267a@github.com>
Message-ID: <QgPsbRGEQrTkudnMTcKFh-HO4c4uUXj4MO2WQZ4YL2I=.a657b09b-6f82-4759-abb3-08925ac75ae3@github.com>

On Fri, 19 Mar 2021 21:23:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixed several broken links to Unicode.org.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments.

Looks all good. Thanks Naoto.

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

Marked as reviewed by joehw (Reviewer).

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

From naoto at openjdk.java.net  Fri Mar 19 21:51:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 21:51:40 GMT
Subject: <i18n dev> Integrated: 8263890: Broken links to Unicode.org
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <NW7A-ciQHcW2ldPntwUqyC-ef7GP6Ow1zpSK935dMY8=.7e10e82e-80de-4ab4-be4e-4d5bdcaa2c45@github.com>

On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed several broken links to Unicode.org.

This pull request has now been integrated.

Changeset: 96e5c3f1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/96e5c3f1
Stats:     37 lines in 8 files changed: 4 ins; 0 del; 33 mod

8263890: Broken links to Unicode.org

Reviewed-by: redestad, joehw, iris

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

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

From pconcannon at openjdk.java.net  Wed Mar 24 10:01:56 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 24 Mar 2021 10:01:56 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof pattern
 variable
Message-ID: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>

Hi,

Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?

Kind regards,
Patrick

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

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 8263668: Update java.time to use instanceof pattern variable

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

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

From lancea at openjdk.java.net  Wed Mar 24 10:44:41 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 24 Mar 2021 10:44:41 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <W7TTMn5vZTP7CwsgIdsEXxoTtkIQXtweQIW_SF3h7qk=.88aeee95-cd17-418d-9041-da141ae41232@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Changes look good Patrick.

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

Marked as reviewed by lancea (Reviewer).

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

From github.com+828220+forax at openjdk.java.net  Wed Mar 24 11:03:51 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 24 Mar 2021 11:03:51 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <Dpzk0f63E8tPAC1zjmQ29kGopHHsyjozKI3AP_EpWCg=.079e6cda-ad0f-4b80-a254-5b3f2888a2eb@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

src/java.base/share/classes/java/time/LocalDateTime.java line 1686:

> 1684:     public long until(Temporal endExclusive, TemporalUnit unit) {
> 1685:         LocalDateTime end = LocalDateTime.from(endExclusive);
> 1686:         if (unit instanceof ChronoUnit u) {

`chronoUnit` is perhaps a better variable name than `u`

src/java.base/share/classes/java/time/LocalTime.java line 1412:

> 1410:         if (unit instanceof ChronoUnit u) {
> 1411:             long nanosUntil = end.toNanoOfDay() - toNanoOfDay();  // no overflow
> 1412:             switch (u) {

same comment as above

src/java.base/share/classes/java/time/MonthDay.java line 448:

> 446:     public long getLong(TemporalField field) {
> 447:         if (field instanceof ChronoField f) {
> 448:             switch (f) {

as above, `chronoField` instead of `f`

src/java.base/share/classes/java/time/OffsetDateTime.java line 599:

> 597:     @Override
> 598:     public int get(TemporalField field) {
> 599:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/OffsetDateTime.java line 636:

> 634:     @Override
> 635:     public long getLong(TemporalField field) {
> 636:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/OffsetTime.java line 1182:

> 1180:         OffsetTime end = OffsetTime.from(endExclusive);
> 1181:         if (unit instanceof ChronoUnit u) {
> 1182:             long nanosUntil = end.toEpochNano() - toEpochNano();  // no overflow

see above

src/java.base/share/classes/java/time/Year.java line 500:

> 498:     public long getLong(TemporalField field) {
> 499:         if (field instanceof ChronoField f) {
> 500:             switch (f) {

see above

src/java.base/share/classes/java/time/Year.java line 711:

> 709:     @Override
> 710:     public Year plus(long amountToAdd, TemporalUnit unit) {
> 711:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/Year.java line 917:

> 915:     public long until(Temporal endExclusive, TemporalUnit unit) {
> 916:         Year end = Year.from(endExclusive);
> 917:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/YearMonth.java line 488:

> 486:     @Override
> 487:     public long getLong(TemporalField field) {
> 488:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/YearMonth.java line 808:

> 806:     @Override
> 807:     public YearMonth plus(long amountToAdd, TemporalUnit unit) {
> 808:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/YearMonth.java line 1049:

> 1047:     public long until(Temporal endExclusive, TemporalUnit unit) {
> 1048:         YearMonth end = YearMonth.from(endExclusive);
> 1049:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/ZonedDateTime.java line 816:

> 814:     @Override  // override for Javadoc and performance
> 815:     public int get(TemporalField field) {
> 816:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/ZonedDateTime.java line 853:

> 851:     @Override
> 852:     public long getLong(TemporalField field) {
> 853:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/chrono/ChronoLocalDateImpl.java line 380:

> 378:         Objects.requireNonNull(endExclusive, "endExclusive");
> 379:         ChronoLocalDate end = getChronology().date(endExclusive);
> 380:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java line 379:

> 377:             if (unit.isTimeBased()) {
> 378:                 long amount = end.getLong(EPOCH_DAY) - date.getLong(EPOCH_DAY);
> 379:                 switch (u) {

see above

src/java.base/share/classes/java/time/chrono/ChronoZonedDateTime.java line 198:

> 196:     @Override
> 197:     default int get(TemporalField field) {
> 198:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/chrono/ChronoZonedDateTime.java line 212:

> 210:     @Override
> 211:     default long getLong(TemporalField field) {
> 212:         if (field instanceof ChronoField f) {

see above

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

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

From github.com+828220+forax at openjdk.java.net  Wed Mar 24 11:09:42 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 24 Mar 2021 11:09:42 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 168:

> 166:     private static final TemporalQuery<ZoneId> QUERY_REGION_ONLY = (temporal) -> {
> 167:         ZoneId zone = temporal.query(TemporalQueries.zoneId());
> 168:         return (zone != null && (!(zone instanceof ZoneOffset)) ? zone : null);

i find this code hard to read
`return (zone != null && (!(zone instanceof ZoneOffset))) ? zone : null;`
seems better`

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

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

From ryadav at openjdk.java.net  Wed Mar 24 12:36:40 2021
From: ryadav at openjdk.java.net (Rahul Yadav)
Date: Wed, 24 Mar 2021 12:36:40 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <0z3is7ycda29bAweHVyYf4foAwjU8uCHCwM0Cq5t6hg=.988e5c6d-b422-4232-b78b-2a0446c328fc@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

LGTM!

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

Marked as reviewed by ryadav (Committer).

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

From naoto at openjdk.java.net  Wed Mar 24 13:05:39 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Mar 2021 13:05:39 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <4uNOFiXg4J3VGd26cDhJ2s7FFrOgNAzjx7yWU57omb8=.9a943351-1ed1-4a68-8114-3ea1c05a76bb@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

LGTM. Thanks for the cleanup!

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

Marked as reviewed by naoto (Reviewer).

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

From rriggs at openjdk.java.net  Wed Mar 24 14:00:42 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 24 Mar 2021 14:00:42 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <wnSAgogvub7uNdnY8-w7gtbWP_G7_Fmto3S2yxFQWm0=.fbc2ded4-61d4-4340-b142-c63c0f673a48@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

In addition to the other suggestions, java.time could use a round of cleanup to use switch expressions.

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

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

From pconcannon at openjdk.java.net  Thu Mar 25 11:18:08 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 25 Mar 2021 11:18:08 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v2]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <hFla6TFxNWyQzHAQWBeT3KY59ImtCMfBVoJW4jJpO2E=.4ec483e2-dd29-4551-8ff8-b260b53c2b12@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 8263668: Update java.time to use instanceof pattern variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/43a57378..b72e658e

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

  Stats: 4370 lines in 292 files changed: 2129 ins; 651 del; 1590 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

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

From naoto at openjdk.java.net  Thu Mar 25 17:53:38 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 25 Mar 2021 17:53:38 GMT
Subject: <i18n dev> RFR: 8262110: DST starts from incorrect time in 2038
Message-ID: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>

Please review the fix to the DST transition bug after the year 2037. The logic had the side effect that it adjusted the dst offset every time the method `getOffsets()` is issued. Only adjust the offset when issued with wall time.

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

Commit messages:
 - Set time zone to the formatter.
 - Added eof
 - Added a test case for 8073446
 - 8262110: DST starts from incorrect time in 2038

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

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

From kcr at openjdk.java.net  Thu Mar 25 20:19:27 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 25 Mar 2021 20:19:27 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <8Vo0sYp5M4FNk6DKP2URAChl60rTHV-MpMsSUQi0-Nk=.c1f6ac22-cc67-4072-8d75-80032979db2f@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

src/java.desktop/share/classes/java/applet/package-info.java line 39:

> 37:  * applet development environment.
> 38:  * <p>
> 39:  * @deprecated.  This package has been deprecated and may be removed in

Package declarations cannot have `@deprecated` tags, so `make docs` fails with this change. Also, since there is a tag here, the previous `<p>` is now empty and causes a warning. Both problems will be fixed by removing the `@deprecated` tag, while leaving the added text.

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

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

From herrick at openjdk.java.net  Thu Mar 25 22:58:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 22:58:53 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 301 additional commits since the last revision:

 - 8189198: Add "forRemoval = true" to Applet API deprecations
 - Merge branch 'master' into 8189198
 - 8260862: JFR: New configure command for the jfr tool
   
   Reviewed-by: mgronlun
 - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
   
   Reviewed-by: bpb
 - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
   
   Reviewed-by: cjplummer, lmesnik, sspitsyn
 - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
   
   Reviewed-by: jnimeh
 - 8253795: Implementation of JEP 391: macOS/AArch64 Port
   8253816: Support macOS W^X
   8253817: Support macOS Aarch64 ABI in Interpreter
   8253818: Support macOS Aarch64 ABI for compiled wrappers
   8253819: Implement os/cpu for macOS/AArch64
   8253839: Update tests and JDK code for macOS/Aarch64
   8254941: Implement Serviceability Agent for macOS/AArch64
   8255776: Change build system for macOS/AArch64
   8262903: [macos_aarch64] Thread::current() called on detached thread
   
   Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
   Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
   Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
   Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
   Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
 - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
   
   Reviewed-by: adinn
 - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
   
   Reviewed-by: herrick, dcubed
 - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
   
   Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
 - ... and 291 more: https://git.openjdk.java.net/jdk/compare/ddfe8ec5...026f09c8

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2920/files
  - new: https://git.openjdk.java.net/jdk/pull/2920/files/1148f208..026f09c8

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

  Stats: 64315 lines in 2948 files changed: 41333 ins; 13022 del; 9960 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2920/head:pull/2920

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

From herrick at openjdk.java.net  Thu Mar 25 22:58:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 22:58:53 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
 <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
 <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>
Message-ID: <tArFXdLPW8vkB0tQ-hZLGWSCFii-IBVY2md9t8TNSD8=.fcac7aad-39cc-4449-a046-6140be9cfbde@github.com>

On Wed, 17 Mar 2021 20:33:09 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>>> I cannot find any instances where the scope can be narrowed
>> 
>> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?
>
>> 
>> 
>> > I cannot find any instances where the scope can be narrowed
>> 
>> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?
> 
> These have the code pattern such as: 
> } else if (c instanceof JApplet) {
> putting '@SuppressWarnings("removal")' before the declaration of 'c' does not help, because the code is not an assignment to 'c'

pushed minor change to src/java.desktop/share/classes/java/applet/package-info.java as well as merge with master.

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

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

From kcr at openjdk.java.net  Thu Mar 25 23:27:37 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 25 Mar 2021 23:27:37 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <LC2l3Zo5eUjQhM6QcVCXZJ7PFh4op_NJSj15xFWPblg=.c02e5303-8b79-4ad8-bc4c-eab62698228f@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/e2285595...026f09c8

Looks good.

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

Marked as reviewed by kcr (Author).

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

From iris at openjdk.java.net  Thu Mar 25 23:38:33 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 25 Mar 2021 23:38:33 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <Ge5orwjsQQS4sJiLXFYz2nVh9v4HCBf1tz3WlVpSGlU=.f6a8deb3-c66a-4eea-b35e-76a82c2fbf73@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/8fcfe0bd...026f09c8

Marked as reviewed by iris (Reviewer).

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

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

From prr at openjdk.java.net  Thu Mar 25 23:51:33 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 25 Mar 2021 23:51:33 GMT
Subject: <i18n dev> RFR: 8189198: Add "forRemoval = true" to Applet API
 deprecations [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <rX_M7QysdLlKt6uprI4OE3kPj_x721_7gNHPw8Q52aQ=.952d1e25-d194-408d-a50d-b92cc8c5c7c4@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/00b7b36f...026f09c8

Marked as reviewed by prr (Reviewer).

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

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

From rriggs at openjdk.java.net  Fri Mar 26 14:33:24 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 26 Mar 2021 14:33:24 GMT
Subject: <i18n dev> RFR: 8262110: DST starts from incorrect time in 2038
In-Reply-To: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>
References: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>
Message-ID: <ngZVQ-jS9H66wG-LA06_h3upo8gCqLUQ73Erc6mzkJE=.94b8a01f-545c-49e4-862d-3218d68c31e0@github.com>

On Tue, 23 Mar 2021 23:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the DST transition bug after the year 2037. The logic had the side effect that it adjusted the dst offset every time the method `getOffsets()` is issued. Only adjust the offset when issued with wall time.

Marked as reviewed by rriggs (Reviewer).

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

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

From herrick at openjdk.java.net  Fri Mar 26 14:51:28 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 26 Mar 2021 14:51:28 GMT
Subject: <i18n dev> Integrated: 8189198: Add "forRemoval = true" to Applet
 API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <4WWT8Ziy2C8n3V8-SQqJ_SNHpYlyB1uO26I-Szzm29c=.d2041dca-362a-4285-a961-7f71635df559@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

This pull request has now been integrated.

Changeset: 57115fa2
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57115fa2
Stats:     73 lines in 22 files changed: 14 ins; 0 del; 59 mod

8189198: Add "forRemoval = true" to Applet API deprecations

Reviewed-by: iris, almatvee, kcr, prr

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

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

From naoto at openjdk.java.net  Fri Mar 26 17:18:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 26 Mar 2021 17:18:30 GMT
Subject: <i18n dev> Integrated: 8262110: DST starts from incorrect time in
 2038
In-Reply-To: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>
References: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>
Message-ID: <Qjoy4uJyCKL32lgHW_lSxqqmwwekiA_6v18NlihQmqI=.1794a471-6316-4d21-bf8c-a9c55c2272eb@github.com>

On Tue, 23 Mar 2021 23:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the DST transition bug after the year 2037. The logic had the side effect that it adjusted the dst offset every time the method `getOffsets()` is issued. Only adjust the offset when issued with wall time.

This pull request has now been integrated.

Changeset: 7284f013
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7284f013
Stats:     75 lines in 2 files changed: 73 ins; 0 del; 2 mod

8262110: DST starts from incorrect time in 2038
8073446: TimeZone getOffset API does not  return a dst offset between years 2038-2137

Reviewed-by: rriggs

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

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

From github.com+76791+alblue at openjdk.java.net  Sun Mar 28 14:02:47 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Sun, 28 Mar 2021 14:02:47 GMT
Subject: <i18n dev> RFR: 8264332: Use the blessed modifier order in
 jdk.charsets
Message-ID: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>

8264332: Use the blessed modifier order in jdk.charsets

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

Commit messages:
 - 8264332: Use the blessed modifier order in jdk.charsets

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

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

From alanb at openjdk.java.net  Mon Mar 29 10:31:28 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 29 Mar 2021 10:31:28 GMT
Subject: <i18n dev> RFR: 8264332: Use the blessed modifier order in
 jdk.charsets
In-Reply-To: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
References: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
Message-ID: <mLxrAOoLzAwtbsMdnfchANuopPYnLb5eaxQgCSVzIV8=.94665e0c-7ec8-4aad-9f26-5832e38c32b6@github.com>

On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264332: Use the blessed modifier order in jdk.charsets

Marked as reviewed by alanb (Reviewer).

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

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

From github.com+76791+alblue at openjdk.java.net  Mon Mar 29 13:36:26 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Mon, 29 Mar 2021 13:36:26 GMT
Subject: <i18n dev> Integrated: 8264332: Use the blessed modifier order in
 jdk.charsets
In-Reply-To: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
References: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
Message-ID: <iSwvVwyzTpxHb9YS2Q3dNe3qGGFy-faARpaiF3VyZk8=.7f1d7170-d0f9-403e-8450-6fe10d38a8d8@github.com>

On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264332: Use the blessed modifier order in jdk.charsets

This pull request has now been integrated.

Changeset: 364cce14
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/364cce14
Stats:     56 lines in 6 files changed: 0 ins; 0 del; 56 mod

8264332: Use the blessed modifier order in jdk.charsets

Reviewed-by: alanb, shade

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

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

From shade at openjdk.java.net  Mon Mar 29 13:36:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 29 Mar 2021 13:36:25 GMT
Subject: <i18n dev> RFR: 8264332: Use the blessed modifier order in
 jdk.charsets
In-Reply-To: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
References: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
Message-ID: <QzacK00OM0pdqCCzbILYAWzbVWzFlx3lo0eGoowFo7U=.a5a2f37a-6471-4f2b-b2c7-e217bd0a0dbd@github.com>

On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264332: Use the blessed modifier order in jdk.charsets

Marked as reviewed by shade (Reviewer).

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

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

From darcy at openjdk.java.net  Mon Mar 29 21:21:02 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Mar 2021 21:21:02 GMT
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
Message-ID: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>

8264148: Update spec for exceptions retrofitted for exception chaining

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

Commit messages:
 - Respond to review feedback.
 - Respond to review feedback.
 - Merge branch 'master' into 8264148
 - Merge branch 'master' into 8264148
 - 8264148: Update spec for exceptions retrofitted for exception chaining

Changes: https://git.openjdk.java.net/jdk/pull/3182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3182&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264148
  Stats: 84 lines in 22 files changed: 8 ins; 44 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3182/head:pull/3182

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

From smarks at openjdk.java.net  Mon Mar 29 21:21:02 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 29 Mar 2021 21:21:02 GMT
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted
 for exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`.

(The considerations for the JDK itself are different, though, which is why I support changing the call sites.)

One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.

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

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

From darcy at openjdk.java.net  Mon Mar 29 21:21:03 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Mar 2021 21:21:03 GMT
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted
 for exception chaining
In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: <YGY3e5JZUid7DXjezumgNg-peG8xsYydHM1F_ZVbZ7o=.f2c5de76-0340-43aa-9698-dec84018dc6a@github.com>

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> 8264148: Update spec for exceptions retrofitted for exception chaining
>
> The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`.
> 
> (The considerations for the JDK itself are different, though, which is why I support changing the call sites.)
> 
> One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.

Some discussion of the proposed changes here. While the history with respect to the introduction of the chained exception mechanism may have been relevant in times past, those comments have little utility today. Per guidance from Dr. Deprecator, I've removed deprecation of the redundant methods and only kept deprecation of the mutable field in WriteAbortedException.

The legacy wrapped exception accessing methods in ClassNotFoundException, ExceptionInInitializerError, and UndeclaredThrowableException are equivalent to getCause. The legacy method in PrivilegedActionException returns the same value, but narrowed to Exception rather than Throwable.

Once the rest of the change is agree to, I'll update copyrights and do a CSR for the deprecation and other spec changes.

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

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

From github.com+28367473+jmehrens at openjdk.java.net  Tue Mar 30 04:01:57 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Tue, 30 Mar 2021 04:01:57 GMT
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted
 for exception chaining
In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: <dGNio-0tGjN8jEVGIMK8y212esY7r1g9L8CjyJYbcDE=.a43a1fd2-9dba-4971-96c1-d84a716f746a@github.com>

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.


Agreed. WriteAbortedException should get similar treatment as the others like it:

- http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016908.html
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html
- https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051341.html

The only twist is that we would have to keep the public field as deprecated.

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

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

From rriggs at openjdk.java.net  Tue Mar 30 13:29:23 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 30 Mar 2021 13:29:23 GMT
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted
 for exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

I agree that the public field in WriteAbortedException could be remediated.
But it is also mostly harmless.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62:

> 60:     catch (java.lang.reflect.InvocationTargetException ite) {
> 61:         if (ite.getCause() instanceof RuntimeException) {
> 62:             throw (RuntimeException)ite.getCause();

This might be a place to use the new instanceof pattern form:
`if (ite.getCause() instanceof RuntimeException rex)
        throw rex.getCause();
`

src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293:

> 291:             Throwable t = e.getCause();
> 292:             if (t instanceof Exception) {
> 293:                 throw (Exception) t;

Ditto:
 ` if (t instanceof Exception ex) throw ex`

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

Marked as reviewed by rriggs (Reviewer).

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

From github.com+28367473+jmehrens at openjdk.java.net  Tue Mar 30 13:43:22 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Tue, 30 Mar 2021 13:43:22 GMT
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted
 for exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

src/java.base/share/classes/java/io/WriteAbortedException.java line 86:

> 84:     @Override
> 85:     public Throwable getCause() {
> 86:         return detail;

Use SuppressWarnings??

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

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

From joe.darcy at oracle.com  Tue Mar 30 15:55:20 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 08:55:20 -0700
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted
 for exception chaining
In-Reply-To: <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>
Message-ID: <76cee601-67a3-adbd-ea45-ded1f2dc592e@oracle.com>


On 3/30/2021 6:43 AM, jmehrens wrote:
> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> 8264148: Update spec for exceptions retrofitted for exception chaining
> src/java.base/share/classes/java/io/WriteAbortedException.java line 86:
>
>> 84:     @Override
>> 85:     public Throwable getCause() {
>> 86:         return detail;
> Use SuppressWarnings??


There is no warning to suppress since the detail field is defined in the 
same class.

-Joe


From joe.darcy at oracle.com  Tue Mar 30 16:00:50 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 09:00:50 -0700
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted
 for exception chaining
In-Reply-To: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>
Message-ID: <0627b7e4-6db3-50bc-fba5-35877647d038@oracle.com>


On 3/30/2021 6:29 AM, Roger Riggs wrote:
> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> 8264148: Update spec for exceptions retrofitted for exception chaining
> I agree that the public field in WriteAbortedException could be remediated.
> But it is also mostly harmless.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62:
>
>> 60:     catch (java.lang.reflect.InvocationTargetException ite) {
>> 61:         if (ite.getCause() instanceof RuntimeException) {
>> 62:             throw (RuntimeException)ite.getCause();
> This might be a place to use the new instanceof pattern form:
> `if (ite.getCause() instanceof RuntimeException rex)
>          throw rex.getCause();
> `
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293:
>
>> 291:             Throwable t = e.getCause();
>> 292:             if (t instanceof Exception) {
>> 293:                 throw (Exception) t;
> Ditto:
>   ` if (t instanceof Exception ex) throw ex`
>

I think the use of the new instanceof form would be better left for a 
follow-up refactoring.

Thanks,

-Joe


From smarks at openjdk.java.net  Tue Mar 30 17:06:32 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 30 Mar 2021 17:06:32 GMT
Subject: <i18n dev> RFR: 8264148: Update spec for exceptions retrofitted
 for exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <XaOfh6DMc2x_a0qsP15eZNL4BNIlr5sZdA5in2dfBVo=.ae0724db-ccc6-4f84-ab43-d698b3042113@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

Marked as reviewed by smarks (Reviewer).

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

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

From darcy at openjdk.java.net  Tue Mar 30 20:03:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 30 Mar 2021 20:03:18 GMT
Subject: <i18n dev> Integrated: 8264148: Update spec for exceptions
 retrofitted for exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <DLYKwabnY95L4xZ2RniMmrgFe7bbxZx5oq6uzIP-wvE=.8605c32a-3628-444e-bc16-8546bfaa87c1@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

This pull request has now been integrated.

Changeset: 815248ab
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/815248ab
Stats:     84 lines in 22 files changed: 8 ins; 44 del; 32 mod

8264148: Update spec for exceptions retrofitted for exception chaining

Reviewed-by: rriggs, smarks

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

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