From naoto at openjdk.java.net  Thu Apr  1 21:04:29 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 1 Apr 2021 21:04:29 GMT
Subject: <i18n dev> RFR: 8264544: Case-insensitive comparison issue with
 supplementary characters.
Message-ID: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>

Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

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

Commit messages:
 - 8264544: Case-insensitive comparison issue with supplementary characters.

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

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

From joehw at openjdk.java.net  Thu Apr  1 22:35:22 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 1 Apr 2021 22:35:22 GMT
Subject: <i18n dev> RFR: 8264544: Case-insensitive comparison issue with
 supplementary characters.
In-Reply-To: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
References: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
Message-ID: <vN8FGFeOSfM1ueg8T0W2Xh-ghpjZDcycXf5ezyTonFI=.81a5324a-4078-488e-9ca6-11b0828ad594@github.com>

On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

Marked as reviewed by joehw (Reviewer).

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

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

From iris at openjdk.java.net  Thu Apr  1 22:48:25 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 1 Apr 2021 22:48:25 GMT
Subject: <i18n dev> RFR: 8264544: Case-insensitive comparison issue with
 supplementary characters.
In-Reply-To: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
References: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
Message-ID: <cjesnh9zr2KJpmIcAFrB81Gr4AaETp-an79klF3ZVag=.93dcfb86-8ecb-4fee-94a9-ee9114d6e26e@github.com>

On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

Marked as reviewed by iris (Reviewer).

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

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

From alanb at openjdk.java.net  Fri Apr  2 08:09:19 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 2 Apr 2021 08:09:19 GMT
Subject: <i18n dev> RFR: 8264544: Case-insensitive comparison issue with
 supplementary characters.
In-Reply-To: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
References: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
Message-ID: <DvgSbZ1DzT3lVeAqbG-ZWWxJ25Bjaba57Ch4iAXHD0s=.da81f7c1-c8bf-4a75-814f-833b86a93733@github.com>

On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

Marked as reviewed by alanb (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Apr  2 16:36:21 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 2 Apr 2021 16:36:21 GMT
Subject: <i18n dev> Integrated: 8264544: Case-insensitive comparison issue
 with supplementary characters.
In-Reply-To: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
References: <a_-ihL9VZzVmHEbm5eMgBfBzXWugVZEQMwPBpRs--Eo=.143b539e-b8fc-4aa9-8422-4744981926b0@github.com>
Message-ID: <YvO3fUqJ_4PhXxktKL5067WPGEoGkIps-xJG-PHgwEQ=.e20acbb5-596a-487d-bdf4-87aa9243c5a1@github.com>

On Thu, 1 Apr 2021 03:24:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. Thanks to the contribution by Chris Johnson.

This pull request has now been integrated.

Changeset: 6c145c47
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6c145c47
Stats:     11 lines in 3 files changed: 3 ins; 0 del; 8 mod

8264544: Case-insensitive comparison issue with supplementary characters.

Co-authored-by: Chris Johnson <chriswjohnson.jdk at gmail.com>
Reviewed-by: joehw, iris, alanb

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

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

From sspitsyn at openjdk.java.net  Fri Apr  2 17:17:24 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Fri, 2 Apr 2021 17:17:24 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: <CU8ip-eXtf0s8gc20flTzNVYfthdqwqcHzBbxQp_7Bc=.cb558101-29c9-4e5f-8334-6b5e8c79ecd3@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

Joe,
The Serviceability part looks good.
Thanks,
Serguei

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

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

From igraves at openjdk.java.net  Tue Apr  6 20:42:50 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 6 Apr 2021 20:42:50 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits
Message-ID: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>

This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

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

Commit messages:
 - Fixing rounding issue with BigDecimal and %g formatting flags

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

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

From darcy at openjdk.java.net  Tue Apr  6 22:59:31 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 6 Apr 2021 22:59:31 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits
In-Reply-To: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
Message-ID: <GuVfVyp43DBMH5Bx36KivqlL02tdk0JqzMIOJKADHDg=.932a5542-321e-4680-88e8-a73f4c53e11b@github.com>

On Tue, 6 Apr 2021 20:34:52 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

test/jdk/java/util/Formatter/BigDecimalRounding.java line 44:

> 42:     public static void testBigDecimalRounding() {
> 43:         var res1 = String.format("%g", 0.00009999999999999995);
> 44:         var res2 = String.format("%g", 0.00009999999f);

To avoid possible vagaries in decimal -> binary conversion of double values, I suggest also testing against a BigDecimal directly rounded to the precision in question.

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

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

From igraves at openjdk.java.net  Wed Apr  7 02:48:00 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 7 Apr 2021 02:48:00 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits [v2]
In-Reply-To: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
Message-ID: <O2mswzonqSXwR182cYYrlA7-lRwGnOCUav_bpVD5EjE=.4f6b2e1c-8fdc-4455-b561-1892804e1788@github.com>

> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

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

  Adding BigDecimal equivalents to tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3363/files
  - new: https://git.openjdk.java.net/jdk/pull/3363/files/8ec00f8f..cf40421e

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

  Stats: 10 lines in 1 file changed: 5 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3363.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3363/head:pull/3363

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

From igraves at openjdk.java.net  Wed Apr  7 03:00:36 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 7 Apr 2021 03:00:36 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits [v2]
In-Reply-To: <GuVfVyp43DBMH5Bx36KivqlL02tdk0JqzMIOJKADHDg=.932a5542-321e-4680-88e8-a73f4c53e11b@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <GuVfVyp43DBMH5Bx36KivqlL02tdk0JqzMIOJKADHDg=.932a5542-321e-4680-88e8-a73f4c53e11b@github.com>
Message-ID: <AJFhToPnN24rgn3sPAq_YDPZgnrAv9CMewdrLnJAxIo=.6bd6010e-3764-48b4-9056-e7194136f2b6@github.com>

On Tue, 6 Apr 2021 22:56:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding BigDecimal equivalents to tests
>
> test/jdk/java/util/Formatter/BigDecimalRounding.java line 44:
> 
>> 42:     public static void testBigDecimalRounding() {
>> 43:         var res1 = String.format("%g", 0.00009999999999999995);
>> 44:         var res2 = String.format("%g", 0.00009999999f);
> 
> To avoid possible vagaries in decimal -> binary conversion of double values, I suggest also testing against a BigDecimal directly rounded to the precision in question.

Good thought, thanks.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Apr  8 08:38:38 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: Thu, 8 Apr 2021 08:38:38 GMT
Subject: <i18n dev> RFR: 8264896: Remove redundant '& 0xFF' from int-to-byte
 cast
Message-ID: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>

When we do
byte b1 = (byte) (value & 0xFF);
we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below:
public class Main {
  public static void main(String[] args) throws Exception {
    IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> {
      byte b1 = (byte) (value & 0xFF);
      byte b2 = (byte) value;
      if (b1 != b2) {
        throw new RuntimeException("" + value);
      }
    });
}

Also tier1 and tier2 are both OK.

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

Commit messages:
 - Merge branch 'master' into bitwise
 - Remove redundant '& 0xFF' from int-to-byte cast

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Apr  8 08:50:09 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: Thu, 8 Apr 2021 08:50:09 GMT
Subject: <i18n dev> RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <VSPKLm1HjhCkd_WmlFJCikNyedxejJnBZ0JOwUxb87k=.35ea99d2-b3d4-4203-b9f2-2a2548262dcb@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>
 <VSPKLm1HjhCkd_WmlFJCikNyedxejJnBZ0JOwUxb87k=.35ea99d2-b3d4-4203-b9f2-2a2548262dcb@github.com>
Message-ID: <z_O5Zecq1WILtXpfu3dEG_tJv-XeXKUW1oU9U6rE7yo=.504befcb-9d96-44de-ae1b-a8d5f0f871d8@github.com>

On Mon, 15 Mar 2021 06:56:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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).

@AlanBateman looks like `List.add(o, i)` is not used at all in scope of these changes.

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

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

From github.com+1204330+overheadhunter at openjdk.java.net  Thu Apr  8 08:57:17 2021
From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel)
Date: Thu, 8 Apr 2021 08:57:17 GMT
Subject: <i18n dev> RFR: 8264896: Remove redundant '& 0xFF' from
 int-to-byte cast
In-Reply-To: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>
References: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>
Message-ID: <vFic_EPGM_JbsjsHk8ZbTqFFeHA5AHpMqeEd9HZ6X_o=.069ccba6-25d6-44bc-8252-ebda302b4abe@github.com>

On Thu, 4 Mar 2021 12:16:29 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> When we do
> byte b1 = (byte) (value & 0xFF);
> we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below:
> public class Main {
>   public static void main(String[] args) throws Exception {
>     IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> {
>       byte b1 = (byte) (value & 0xFF);
>       byte b2 = (byte) value;
>       if (b1 != b2) {
>         throw new RuntimeException("" + value);
>       }
>     });
> }
> 
> Also tier1 and tier2 are both OK.

I don't think these masks have been added because they are _required_ but rather because they explicitly show the intention: You can immediately see that losing the MSBs of an int during the cast is _not_ just an error.

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

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

From dfuchs at openjdk.java.net  Thu Apr  8 09:11:18 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 8 Apr 2021 09:11:18 GMT
Subject: <i18n dev> RFR: 8264896: Remove redundant '& 0xFF' from
 int-to-byte cast
In-Reply-To: <vFic_EPGM_JbsjsHk8ZbTqFFeHA5AHpMqeEd9HZ6X_o=.069ccba6-25d6-44bc-8252-ebda302b4abe@github.com>
References: <T9cLs0tk1TmQ9TiHiQSFuFvT2L49j1_rZ-s6Pl6lFQs=.68fb0dea-9045-4401-9d87-5ca59772501b@github.com>
 <vFic_EPGM_JbsjsHk8ZbTqFFeHA5AHpMqeEd9HZ6X_o=.069ccba6-25d6-44bc-8252-ebda302b4abe@github.com>
Message-ID: <PzxaShiKuvAABtjwY5kHNDZXSGbdKWTICgnJkySn11U=.db83f51f-1d1f-4efc-8d40-ee4a6ff2a185@github.com>

On Thu, 8 Apr 2021 08:54:35 GMT, Sebastian Stenzel <github.com+1204330+overheadhunter at openjdk.org> wrote:

>> When we do
>> byte b1 = (byte) (value & 0xFF);
>> we keep from int only 1 lower byte and exactly the same can be achieved with plain cast. See the test below:
>> public class Main {
>>   public static void main(String[] args) throws Exception {
>>     IntStream.range(Integer.MIN_VALUE, Integer.MAX_VALUE).forEach(value -> {
>>       byte b1 = (byte) (value & 0xFF);
>>       byte b2 = (byte) value;
>>       if (b1 != b2) {
>>         throw new RuntimeException("" + value);
>>       }
>>     });
>> }
>> 
>> Also tier1 and tier2 are both OK.
>
> I don't think these masks have been added because they are _required_ but rather because they explicitly show the intention: You can immediately see that losing the MSBs of an int during the cast is _not_ just an error.

I agree with Sebastian. I believe the original code was clearer.

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

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

From pconcannon at openjdk.java.net  Thu Apr  8 16:01:41 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 8 Apr 2021 16:01:41 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v3]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <pCGsyKhNdxDp6439M6Oc6vbEKvueLqgylxxKCzeMFFU=.978deb3a-f32d-4a06-bbbc-5049fc25cdd2@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 four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 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/b72e658e..d7355049

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

  Stats: 37636 lines in 887 files changed: 29080 ins; 4064 del; 4492 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 joehw at openjdk.java.net  Thu Apr  8 23:50:14 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 8 Apr 2021 23:50:14 GMT
Subject: <i18n dev> 
 =?utf-8?q?RFR=3A_8264765=3A_BreakIterator_sees_bogus_?=
 =?utf-8?q?sentence_boundary_in_parenthesized_=E2=80=9Ci=2Ee=2E=E2=80=9D_p?=
 =?utf-8?q?hrase?=
In-Reply-To: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>
References: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>
Message-ID: <H0I9I1R415L_EdtIqnHFaet2yx0zq-18S1RBQBPdMRM=.13fa0af8-1e51-4fce-9a57-0a8baf33bbbc@github.com>

On Thu, 8 Apr 2021 18:19:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. It is not actually related to "parenthesized", but period-comma sequence was regarded as a break on a backward traverse.

Marked as reviewed by joehw (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Apr  9 18:15:26 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 9 Apr 2021 18:15:26 GMT
Subject: <i18n dev> =?utf-8?q?Integrated=3A_8264765=3A_BreakIterator_sees?=
 =?utf-8?q?_bogus_sentence_boundary_in_parenthesized_=E2=80=9Ci=2Ee=2E?=
 =?utf-8?q?=E2=80=9D_phrase?=
In-Reply-To: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>
References: <RWM--Xx47tXkDwysIImFsvNCqU6H9chw-cqPEzYR9TI=.e70ab795-bac0-4580-bac4-52abe8a61c85@github.com>
Message-ID: <eL-vLLfPXjwo_Wf1B0fWhqPOTby_W2x7raT0gUpbVNU=.58d04cfa-5609-46f3-9313-a3596bee129c@github.com>

On Thu, 8 Apr 2021 18:19:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. It is not actually related to "parenthesized", but period-comma sequence was regarded as a break on a backward traverse.

This pull request has now been integrated.

Changeset: 9ebc497b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9ebc497b
Stats:     19 lines in 2 files changed: 14 ins; 0 del; 5 mod

8264765: BreakIterator sees bogus sentence boundary in parenthesized ?i.e.? phrase

Reviewed-by: joehw

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

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

From jpai at openjdk.java.net  Tue Apr 13 11:50:17 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 13 Apr 2021 11:50:17 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <XgB0BT7zwM3BD39h0-BWlxjVpPG2hAfXqGSMEG-dVCM=.e963a637-1499-4f08-8af9-0af1fee96008@github.com>

On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

While we are at this, the `Calendar.getDisplayNames(...)` states this:

> ....
> @throws    IllegalArgumentException
     *        if {@code field} or {@code style} is invalid,
     *        or if this {@code Calendar} is non-lenient and any
     *        of the calendar fields have invalid values

If I understand this correctly, if the `Calendar` instance was non-lenient and this method returned invalid values for the `AM_PM` field, it should have thrown an `IllegalArgumentException` (which is a strange exception to throw for an invalid result, but that's a different matter). However, with the current code in upstream master, I saw no such exception being thrown (nor do I see any such validating code in the `Calendar` implementation) when the calendar instance was non-lenient. Is that expected?

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

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

From jpai at openjdk.java.net  Tue Apr 13 11:50:17 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 13 Apr 2021 11:50:17 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale
Message-ID: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>

Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?

As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.

The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.

The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.

After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

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

Commit messages:
 - Fix test that now fails after fixing 8262108
 - 8262108: SimpleDateFormat formatting broken for sq_MK Locale

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

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

From jpai at openjdk.java.net  Tue Apr 13 11:55:59 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 13 Apr 2021 11:55:59 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <N2UFimWEQR8kObGXJqSmVZkbIq95VdyfsaXtno1kHhE=.c5ff4887-5646-4c7d-b8e4-41605b2eda77@github.com>

On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java line 201:

> 199:                                 switch (i) {
> 200:                                     case 0, 2, 3, 4, 5 -> map.put(name, AM);
> 201:                                     case 1, 6, 7, 8, 9, 10, 11 -> map.put(name, PM);

One part where I need input here, is the "midnight" and the "noon" types. I haven't found anything in the JDK code which I can use as a reference to classify "midnight" and "noon" as `AM` (which is what this code is doing). The doc here https://unicode.org/reports/tr35/tr35-dates.html#Day_Period_Rules speaks about these 2 types but I don't think it's something that I can use to translate those types into a field value for Calendar, to represent `AM` or `PM`. As such, right now, I've just guessed that `AM` is probably the right value for these types, but there's no technical reason or reference backing it.

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

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

From jpai at openjdk.java.net  Tue Apr 13 15:03:28 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 13 Apr 2021 15:03:28 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v2]
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

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

 - copyright year and @bug id reference in existing test
 - copyright year on source

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3463/files
  - new: https://git.openjdk.java.net/jdk/pull/3463/files/812d54f2..84b11879

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

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

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

From naoto at openjdk.java.net  Tue Apr 13 17:58:57 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 13 Apr 2021 17:58:57 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v2]
In-Reply-To: <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
Message-ID: <vQfvLgmYok7-v_7bt-8T7BtJkZB0Fh4pJnjT7heAzCE=.beb892e4-5d16-41d3-85f6-2a7209753f9f@github.com>

On Tue, 13 Apr 2021 15:03:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year and @bug id reference in existing test
>  - copyright year on source

Have you run regression tests in java.time? If I am not mistaken, your changes simply seem to nullify the day period support.

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

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

From jpai at openjdk.java.net  Wed Apr 14 02:14:57 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 14 Apr 2021 02:14:57 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v2]
In-Reply-To: <vQfvLgmYok7-v_7bt-8T7BtJkZB0Fh4pJnjT7heAzCE=.beb892e4-5d16-41d3-85f6-2a7209753f9f@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
 <vQfvLgmYok7-v_7bt-8T7BtJkZB0Fh4pJnjT7heAzCE=.beb892e4-5d16-41d3-85f6-2a7209753f9f@github.com>
Message-ID: <EsyRp7TVqWQ6XWkLHfizqX0DjvLtv2r0AalyTb64xkY=.60f227fb-5e6e-436b-8675-f3727e3d220e@github.com>

On Tue, 13 Apr 2021 17:56:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>Have you run regression tests in java.time? If I am not mistaken, your changes simply seem to nullify the day period support.

Hello @naotoj, my tier1 test run passed without issues locally with this change:


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier1                     1750  1746     4     0 <<
   jtreg:test/jdk:tier1                               2022  2022     0     0   
   jtreg:test/langtools:tier1                         4158  4158     0     0   
   jtreg:test/jaxp:tier1                                 0     0     0     0   
   jtreg:test/lib-test:tier1                             0     0     0     0   
==============================

(the 4 hotspot failures are unrelated environmental issues).

After seeing your message, I now ran the `java/time` regression tests:


jtreg -jdk:build/macosx-x86_64-server-release/images/jdk/ test/jdk/java/time/
Test results: passed: 184

and even those passed.

I don't have much knowledge in this area of the code, but as far as I can see, this doesn't touch the changes introduced in the java.time to support the new day period construct.

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

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

From naoto at openjdk.java.net  Wed Apr 14 16:04:38 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 16:04:38 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v2]
In-Reply-To: <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <n-L2ypqJE7sKMFI74FGgFSQ7vv6uGaVsDEwF6VxCZDw=.3d6720c7-54a2-45af-87fb-df35171cf3e9@github.com>
Message-ID: <ANqqM9JXBCDik7LhzAf9vvJkN94Ea8Fsmm3FCLTgu8o=.e32683ea-38c2-4b32-a947-69462690e886@github.com>

On Tue, 13 Apr 2021 15:03:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year and @bug id reference in existing test
>  - copyright year on source

Thanks for checking.
`CalendarNameProviderImpl` is an implementation detail, which is shared between `j.u.Calendar` and `j.t.f.DateTimeFormatter(Builder)` class, where it provides localized names for Calendar fields. For the field `Calendar.AM_PM`, it includes not only am/pm translations, but also day periods translations as you see. So blindly mapping day period translations to Calendar.AM/PM index is incorrect. I'd rather modify the code like:

                            if (field == AM_PM && !javatime && i > PM) {
                                continue;
                            } else {
                                map.put(name, base + i);
                            }

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

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

From jpai at openjdk.java.net  Wed Apr 14 17:14:55 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 14 Apr 2021 17:14:55 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v3]
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

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

 - Update existing NarrowNamesTest to match expectations
 - Naoto's review suggestion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3463/files
  - new: https://git.openjdk.java.net/jdk/pull/3463/files/84b11879..e7194733

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

  Stats: 33 lines in 2 files changed: 12 ins; 6 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3463/head:pull/3463

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

From jpai at openjdk.java.net  Wed Apr 14 17:18:44 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 14 Apr 2021 17:18:44 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v3]
In-Reply-To: <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
Message-ID: <eVK9Znvfa28ElqKBZr1j2yypTTPx-SPBjqg9PjIKOuY=.3de7299f-d3ab-4c92-9a81-51187de76563@github.com>

On Wed, 14 Apr 2021 17:14:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update existing NarrowNamesTest to match expectations
>  - Naoto's review suggestion

Hello Naoto,

> CalendarNameProviderImpl is an implementation detail, which is shared between j.u.Calendar and j.t.f.DateTimeFormatter(Builder) class, where it provides localized names for Calendar fields. For the field Calendar.AM_PM, it includes not only am/pm translations, but also day periods translations as you see.

Thank you for those details. That's very helpful.

>I'd rather modify the code like:

                            if (field == AM_PM && !javatime && i > PM) {
                                continue;
                            } else {
                                map.put(name, base + i);
                            }


I've taken your suggestion and updated the code to match this. In the update, I've included a code comment to explain what this block does. Please do let me know if that code comment isn't accurate and needs any updates.

 The new `CalendarDisplayNamesTest` continues to pass with this change. I updated the existing `NarrowNamesTest` to match the expectations of the `Calendar.getDisplayName()` API.

All jtreg tests in `test/jdk/java/util/Calendar` and `test/jdk/java/time/` continue to pass too. I have triggered a local run of `tier1` tests and will check back the results early morning tomorrow.

Thank you for your reviews so far.

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

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

From naoto at openjdk.java.net  Wed Apr 14 18:21:39 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 18:21:39 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v3]
In-Reply-To: <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
Message-ID: <iUjZIPE7jl6ynAxVkX7Em1ZLIwpLz80156uB_M9MAO8=.30e5943f-d743-493d-8729-1bea5ba90be2@github.com>

On Wed, 14 Apr 2021 17:14:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update existing NarrowNamesTest to match expectations
>  - Naoto's review suggestion

Changes requested by naoto (Reviewer).

src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java line 193:

> 191:                             }
> 192:                             if (field == AM_PM && !javatime && i > PM) {
> 193:                                 // when dealing with calendar fields, don't set AM_PM field value

Make it explicit that this block only serves for `java.util.Calendar`, not `java.time.format.DateTimeFormatter(Builder)`.

test/jdk/java/util/Calendar/CalendarDisplayNamesTest.java line 53:

> 51:             for (final int style : styles) {
> 52:                 final Calendar cal = Calendar.getInstance();
> 53:                 cal.setLenient(false);

Don't think leniency is relevant here.

test/jdk/java/util/Calendar/NarrowNamesTest.java line 119:

> 117:             expectedFieldValues.put("a", Calendar.AM);
> 118:             expectedFieldValues.put("p", Calendar.PM);
> 119:             testAM_PM(US, ALL_STYLES, expectedFieldValues);

I believe this can be reverted to the original, as the original code compares the exact map (including the length of the map).  , i.e., 

           testMap(US, AM_PM, ALL_STYLES,
                    "AM", "PM",
                    RESET_INDEX,
                    "a", "p");

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

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

From naoto at openjdk.java.net  Wed Apr 14 21:21:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 21:21:10 GMT
Subject: <i18n dev> RFR: 8258794: Support for CLDR version 39
Message-ID: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>

Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

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

Commit messages:
 - 8258794: Support for CLDR version 39
 - CLDR 38.1

Changes: https://git.openjdk.java.net/jdk/pull/3502/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3502&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258794
  Stats: 26326 lines in 815 files changed: 761 ins; 23140 del; 2425 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3502.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3502/head:pull/3502

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

From joehw at openjdk.java.net  Wed Apr 14 21:54:43 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 14 Apr 2021 21:54:43 GMT
Subject: <i18n dev> RFR: 8258794: Support for CLDR version 39
In-Reply-To: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
References: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
Message-ID: <dVqVOfj97RMC84t7-YM1oLv7_urFf0RndlAHGgPRItQ=.1a4e2333-98c4-4e89-927f-59083dc88c36@github.com>

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

Naoto, are you testing GitHub ('s ability to handle a large number of files) ;-)

Indeed, the majority changes were version and copyright. If you hadn't mentioned the changed class, it would be almost impossible to find it :-)

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

Marked as reviewed by joehw (Reviewer).

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

From naoto at openjdk.java.net  Wed Apr 14 22:01:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Apr 2021 22:01:40 GMT
Subject: <i18n dev> RFR: 8258794: Support for CLDR version 39
In-Reply-To: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
References: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
Message-ID: <J4PLvADNaDPY-haDWW90tPTfI9tWJcapaowlhP9ZYi8=.0f98db23-5d04-4181-a282-e7cbe4bae425@github.com>

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

Thanks, Joe.

> Naoto, are you testing GitHub ('s ability to handle a large number of files) ;-)

CLDR itself has been hosted on GitHub too, so it shouldn't be a problem ??

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

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

From erikj at openjdk.java.net  Wed Apr 14 22:30:13 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 14 Apr 2021 22:30:13 GMT
Subject: <i18n dev> RFR: 8258794: Support for CLDR version 39
In-Reply-To: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
References: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
Message-ID: <5HWDRokYdhdJciJWcGWySJoDe7dTxtIX4nzLA1he1eY=.f67d81f3-8d2d-443a-9f1f-09d5133953fe@github.com>

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

Marked as reviewed by erikj (Reviewer).

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

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

From jpai at openjdk.java.net  Thu Apr 15 01:57:01 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 15 Apr 2021 01:57:01 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v4]
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - update existing testcase based on review comment
 - Improve code comment to be clear it's only applicable for java.util.Calendar
 - Remove irrelevant setLenient from new testcase

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3463/files
  - new: https://git.openjdk.java.net/jdk/pull/3463/files/e7194733..607776b3

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

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

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

From jpai at openjdk.java.net  Thu Apr 15 01:57:03 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 15 Apr 2021 01:57:03 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v3]
In-Reply-To: <iUjZIPE7jl6ynAxVkX7Em1ZLIwpLz80156uB_M9MAO8=.30e5943f-d743-493d-8729-1bea5ba90be2@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <-fgi7OtZtYU_OKFttTi8jnHYLcjMgXKa-5C0VzWNkFY=.05fa0509-cd1d-46cc-b033-e427fa379b14@github.com>
 <iUjZIPE7jl6ynAxVkX7Em1ZLIwpLz80156uB_M9MAO8=.30e5943f-d743-493d-8729-1bea5ba90be2@github.com>
Message-ID: <hRZPlfHktC4SIXpiE874R96FVgfIneIp7DHRCAaGEsM=.bcf8cd86-4a6b-4c96-b931-5fe715dcc62e@github.com>

On Wed, 14 Apr 2021 18:01:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update existing NarrowNamesTest to match expectations
>>  - Naoto's review suggestion
>
> src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java line 193:
> 
>> 191:                             }
>> 192:                             if (field == AM_PM && !javatime && i > PM) {
>> 193:                                 // when dealing with calendar fields, don't set AM_PM field value
> 
> Make it explicit that this block only serves for `java.util.Calendar`, not `java.time.format.DateTimeFormatter(Builder)`.

Hello Naoto, I've now updated the PR to be more explicit in this code comment.

> test/jdk/java/util/Calendar/CalendarDisplayNamesTest.java line 53:
> 
>> 51:             for (final int style : styles) {
>> 52:                 final Calendar cal = Calendar.getInstance();
>> 53:                 cal.setLenient(false);
> 
> Don't think leniency is relevant here.

Removed in the latest update of this PR. This was a leftover from my experimental testing.

> test/jdk/java/util/Calendar/NarrowNamesTest.java line 119:
> 
>> 117:             expectedFieldValues.put("a", Calendar.AM);
>> 118:             expectedFieldValues.put("p", Calendar.PM);
>> 119:             testAM_PM(US, ALL_STYLES, expectedFieldValues);
> 
> I believe this can be reverted to the original, as the original code compares the exact map (including the length of the map).  , i.e., 
> 
>            testMap(US, AM_PM, ALL_STYLES,
>                     "AM", "PM",
>                     RESET_INDEX,
>                     "a", "p");

Done. Reverted this specific part to what it was originally. Test continues to pass with this change and the latest PR update.

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

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

From naoto at openjdk.java.net  Thu Apr 15 04:00:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 15 Apr 2021 04:00:35 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v4]
In-Reply-To: <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
Message-ID: <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>

On Thu, 15 Apr 2021 01:57:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update existing testcase based on review comment
>  - Improve code comment to be clear it's only applicable for java.util.Calendar
>  - Remove irrelevant setLenient from new testcase

Changes requested by naoto (Reviewer).

test/jdk/java/util/Calendar/NarrowNamesTest.java line 115:

> 113:         } else {
> 114:             testMap(US, AM_PM, ALL_STYLES,
> 115:                     "AM", "PM",

What I meant was there is no need to check the providers and introduce the am/pm specific test method. Both `CLDR` and `COMPAT` (i.e., no "if" statement) should be tested with `testMap()` method as other tests do.

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

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

From naoto at openjdk.java.net  Thu Apr 15 21:31:36 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 15 Apr 2021 21:31:36 GMT
Subject: <i18n dev> Integrated: 8258794: Support for CLDR version 39
In-Reply-To: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
References: <jWarTYYrXAklL4tFtd_XGBnGkiTFEoJNabxCWNvBQMw=.14a51b4f-7204-46cd-b7b9-6fa43df81530@github.com>
Message-ID: <UN5NsIpRRh51MnfQn8ey1x8qafTFJ8qALQ36UIP9_9M=.258a6823-e691-43f1-b469-31917a751b54@github.com>

On Wed, 14 Apr 2021 21:13:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the changes to support CLDR version 39. The vast majority of the changes are purely data changes from Unicode. The only change affected in logic was in `CLDRLocaleProviderAdapter.java`, where it needed to deal with CLDR's Norwegian language code switch (https://unicode-org.atlassian.net/browse/CLDR-2698)

This pull request has now been integrated.

Changeset: f6e54f2f
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f6e54f2f
Stats:     26326 lines in 815 files changed: 761 ins; 23140 del; 2425 mod

8258794: Support for CLDR version 39

Reviewed-by: joehw, erikj

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

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

From jpai at openjdk.java.net  Fri Apr 16 02:38:36 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 02:38:36 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v4]
In-Reply-To: <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
 <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>
Message-ID: <v8hvPGYcyBqJArhm8_TyF3cHEXbt04Sx-VPB95Efgis=.6d0280f5-0633-432e-a048-2e32d0551b8b@github.com>

On Thu, 15 Apr 2021 03:57:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - update existing testcase based on review comment
>>  - Improve code comment to be clear it's only applicable for java.util.Calendar
>>  - Remove irrelevant setLenient from new testcase
>
> test/jdk/java/util/Calendar/NarrowNamesTest.java line 115:
> 
>> 113:         } else {
>> 114:             testMap(US, AM_PM, ALL_STYLES,
>> 115:                     "AM", "PM",
> 
> What I meant was there is no need to check the providers and introduce the am/pm specific test method. Both `CLDR` and `COMPAT` (i.e., no "if" statement) should be tested with `testMap()` method as other tests do.

Hello Naoto,

As far as I can see, the testMap cannot be used to test the day period strings. More specifically, consider this change (git diff) that I did as you suggested (unless I misunderstood what you meant):


+        testMap(US, AM_PM, ALL_STYLES,
+                "AM",
+                "PM",
+                "midnight",
+                "noon",
+                "in the morning",
+                "",
+                "in the afternoon",
+                "",
+                "in the evening",
+                "",
+                "at night",
+                "",
+                RESET_INDEX,
+                "a", "p", "mi", "n", "", "", "", "", "", "", "", "");
+        testMap(US, AM_PM, ALL_STYLES,
+                "AM", "PM",
+                RESET_INDEX,
+                "a", "p");



This will fail with the following error.

testMap: locale=en_US, field=9, style=0, expected={in the afternoon=6, in the evening=8, in the morning=4, at night=10, midnight=2, noon=3, AM=0, PM=1, mi=2, a=0, n=3, p=1}, got={AM=0, PM=1, a=0, p=1}
java.lang.RuntimeException: test failed


That failure is due to the `testMap` method expecting these day period string to be part of the returned Map from `Calendar.getDisplayNames()` which won't be the case because that API (as per the javadoc) will only return a Map whose display names have valid field values, so in this case only those display names which will have `AM` or `PM` as a value.

If it's easier to review, I will go ahead and push the suggested change in this testcase and let if fail so that you can get a chance to look at the actual test code and error. Let me know.

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

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

From naoto at openjdk.java.net  Fri Apr 16 03:56:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 03:56:35 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v4]
In-Reply-To: <v8hvPGYcyBqJArhm8_TyF3cHEXbt04Sx-VPB95Efgis=.6d0280f5-0633-432e-a048-2e32d0551b8b@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
 <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>
 <v8hvPGYcyBqJArhm8_TyF3cHEXbt04Sx-VPB95Efgis=.6d0280f5-0633-432e-a048-2e32d0551b8b@github.com>
Message-ID: <P4IP_SUlVoGV9ggcEPenkKGR-Oz7Ar9eX2wxlxnqxZk=.500680d5-6c3e-4444-8c0f-d443e4753e4f@github.com>

On Fri, 16 Apr 2021 02:35:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/util/Calendar/NarrowNamesTest.java line 115:
>> 
>>> 113:         } else {
>>> 114:             testMap(US, AM_PM, ALL_STYLES,
>>> 115:                     "AM", "PM",
>> 
>> What I meant was there is no need to check the providers and introduce the am/pm specific test method. Both `CLDR` and `COMPAT` (i.e., no "if" statement) should be tested with `testMap()` method as other tests do.
>
> Hello Naoto,
> 
> As far as I can see, the testMap cannot be used to test the day period strings. More specifically, consider this change (git diff) that I did as you suggested (unless I misunderstood what you meant):
> 
> 
> +        testMap(US, AM_PM, ALL_STYLES,
> +                "AM",
> +                "PM",
> +                "midnight",
> +                "noon",
> +                "in the morning",
> +                "",
> +                "in the afternoon",
> +                "",
> +                "in the evening",
> +                "",
> +                "at night",
> +                "",
> +                RESET_INDEX,
> +                "a", "p", "mi", "n", "", "", "", "", "", "", "", "");
> +        testMap(US, AM_PM, ALL_STYLES,
> +                "AM", "PM",
> +                RESET_INDEX,
> +                "a", "p");
> 
> 
> 
> This will fail with the following error.
> 
> testMap: locale=en_US, field=9, style=0, expected={in the afternoon=6, in the evening=8, in the morning=4, at night=10, midnight=2, noon=3, AM=0, PM=1, mi=2, a=0, n=3, p=1}, got={AM=0, PM=1, a=0, p=1}
> java.lang.RuntimeException: test failed
> 
> 
> That failure is due to the `testMap` method expecting these day period string to be part of the returned Map from `Calendar.getDisplayNames()` which won't be the case because that API (as per the javadoc) will only return a Map whose display names have valid field values, so in this case only those display names which will have `AM` or `PM` as a value.
> 
> If it's easier to review, I will go ahead and push the suggested change in this testcase and let if fail so that you can get a chance to look at the actual test code and error. Let me know.

Sorry if I wasn't clear. The whole test for am/pm (line 98 - 118) can simply be:

            testMap(US, AM_PM, ALL_STYLES,
                    "AM", "PM",
                    RESET_INDEX,
                    "a", "p");

Since we now know that day periods strings won't be leaked into display names, then the map simply should contain only 4 entries (`AM`, `PM`, `a`, and `p`).

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

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

From jpai at openjdk.java.net  Fri Apr 16 04:06:54 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 04:06:54 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v4]
In-Reply-To: <P4IP_SUlVoGV9ggcEPenkKGR-Oz7Ar9eX2wxlxnqxZk=.500680d5-6c3e-4444-8c0f-d443e4753e4f@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <WA4buqyLzf-liiFAzzi5k4CQ3WcTB-86OoKG1yHVRaM=.d18a2579-52a9-410f-9813-18ecc4c901f0@github.com>
 <C2JtTJDDhIGvvsi52AFORaocqb1E_P_hiliac59bEhY=.d5aefa91-4229-4c24-b4b4-f1d465e8d824@github.com>
 <v8hvPGYcyBqJArhm8_TyF3cHEXbt04Sx-VPB95Efgis=.6d0280f5-0633-432e-a048-2e32d0551b8b@github.com>
 <P4IP_SUlVoGV9ggcEPenkKGR-Oz7Ar9eX2wxlxnqxZk=.500680d5-6c3e-4444-8c0f-d443e4753e4f@github.com>
Message-ID: <6adYjCCfmbNAFRUD2cHge7uj7Ttf_PGzNb75zrnkEJY=.dc685641-9ab8-4b75-b109-debe4a91f792@github.com>

On Fri, 16 Apr 2021 03:51:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello Naoto,
>> 
>> As far as I can see, the testMap cannot be used to test the day period strings. More specifically, consider this change (git diff) that I did as you suggested (unless I misunderstood what you meant):
>> 
>> 
>> +        testMap(US, AM_PM, ALL_STYLES,
>> +                "AM",
>> +                "PM",
>> +                "midnight",
>> +                "noon",
>> +                "in the morning",
>> +                "",
>> +                "in the afternoon",
>> +                "",
>> +                "in the evening",
>> +                "",
>> +                "at night",
>> +                "",
>> +                RESET_INDEX,
>> +                "a", "p", "mi", "n", "", "", "", "", "", "", "", "");
>> +        testMap(US, AM_PM, ALL_STYLES,
>> +                "AM", "PM",
>> +                RESET_INDEX,
>> +                "a", "p");
>> 
>> 
>> 
>> This will fail with the following error.
>> 
>> testMap: locale=en_US, field=9, style=0, expected={in the afternoon=6, in the evening=8, in the morning=4, at night=10, midnight=2, noon=3, AM=0, PM=1, mi=2, a=0, n=3, p=1}, got={AM=0, PM=1, a=0, p=1}
>> java.lang.RuntimeException: test failed
>> 
>> 
>> That failure is due to the `testMap` method expecting these day period string to be part of the returned Map from `Calendar.getDisplayNames()` which won't be the case because that API (as per the javadoc) will only return a Map whose display names have valid field values, so in this case only those display names which will have `AM` or `PM` as a value.
>> 
>> If it's easier to review, I will go ahead and push the suggested change in this testcase and let if fail so that you can get a chance to look at the actual test code and error. Let me know.
>
> Sorry if I wasn't clear. The whole test for am/pm (line 98 - 118) can simply be:
> 
>             testMap(US, AM_PM, ALL_STYLES,
>                     "AM", "PM",
>                     RESET_INDEX,
>                     "a", "p");
> 
> Since we now know that day periods strings won't be leaked into display names, then the map simply should contain only 4 entries (`AM`, `PM`, `a`, and `p`).

Thank you for that clarification. I now understand what you mean. I've updated the test to follow this suggestion in the latest update to this PR.

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

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

From jpai at openjdk.java.net  Fri Apr 16 04:06:54 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 04:06:54 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v5]
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

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

  Update existing test based on review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3463/files
  - new: https://git.openjdk.java.net/jdk/pull/3463/files/607776b3..ea0d3c77

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

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

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

From naoto at openjdk.java.net  Fri Apr 16 04:22:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 04:22:37 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v5]
In-Reply-To: <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>
Message-ID: <M4MGC-RYTP0oLVXTVfY03iXuIiIp2Zs_t4zsotprhOE=.921a18cd-4dc8-49d3-bf3f-d6918cbf1b17@github.com>

On Fri, 16 Apr 2021 04:06:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update existing test based on review comments

Looks good. Thank you for fixing the issue.

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

Marked as reviewed by naoto (Reviewer).

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

From jpai at openjdk.java.net  Fri Apr 16 06:48:37 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 06:48:37 GMT
Subject: <i18n dev> RFR: 8262108: SimpleDateFormat formatting broken for
 sq_MK Locale [v5]
In-Reply-To: <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
 <JpeSggAn3ibWQea7_jh5G8A47sFoKy2pzP_E2gRbozw=.29ef1d8a-0411-4090-ad24-9b406de9bd52@github.com>
Message-ID: <Sc1dddQ7enVWUD6_u8644UO3--If8xJ0kWyhqpyA0xU=.44399949-33d3-4484-b0a9-15b33ae085c1@github.com>

On Fri, 16 Apr 2021 04:06:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
>> 
>> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
>> 
>> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
>> 
>> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
>> 
>> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update existing test based on review comments

Thank you Naoto for your reviews and guidance in fixing this issue.

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

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

From jpai at openjdk.java.net  Fri Apr 16 06:48:39 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 16 Apr 2021 06:48:39 GMT
Subject: <i18n dev> Integrated: 8262108: SimpleDateFormat formatting broken
 for sq_MK Locale
In-Reply-To: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
References: <atpYFvAt19IfPvzE7rScH55suyfapxdkN-6JUgKBu4E=.0d6f641d-26a8-4222-a399-a104a3053faf@github.com>
Message-ID: <97UbBWokWjmUgpXG9C_gP7hoeoJHribfqbWTpYJwILY=.c88a6414-ea6d-4ded-8f1c-dd3d985895b7@github.com>

On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8262108?
> 
> As noted in a comment in that issue, the bug relates to the return value of `Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation has started returning invalid values for the `AM_PM` field after the "day period" support was added recently in the JDK as part of https://bugs.openjdk.java.net/browse/JDK-8262108.
> 
> The commit here adds a check in the internal implementation of the display name handling logic, to special case the `AM_PM` field and properly convert the display name array indexes (which is an internal detail) to valid values that represent the `AM_PM` calendar field.
> 
> The commit also has a new jtreg test case `CalendarDisplayNamesTest` reproduces this issue and verifies the fix.
> 
> After this fix was introduced, I ran the test in `test/jdk/java/util/Calendar/` and that showed up a failure in an existing test case `NarrowNamesTest`. Looking at that test case, IMO, the current testing in that `NarrowNamesTest` is incorrect and is probably what hid this issue in the first place? To fix this, I have added an additional commit which updates this test case to properly test the `AM_PM` field values.

This pull request has now been integrated.

Changeset: 64e21307
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/64e21307
Stats:     99 lines in 3 files changed: 73 ins; 18 del; 8 mod

8262108: SimpleDateFormat formatting broken for sq_MK Locale

Reviewed-by: naoto

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

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

From rriggs at openjdk.java.net  Fri Apr 16 14:30:38 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Apr 2021 14:30:38 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits [v2]
In-Reply-To: <O2mswzonqSXwR182cYYrlA7-lRwGnOCUav_bpVD5EjE=.4f6b2e1c-8fdc-4455-b561-1892804e1788@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <O2mswzonqSXwR182cYYrlA7-lRwGnOCUav_bpVD5EjE=.4f6b2e1c-8fdc-4455-b561-1892804e1788@github.com>
Message-ID: <GhkZVYo0g3PkRg-ZYddWBne9V_cxU6nhm0jkWOssUoA=.9b5476b9-2261-42a3-90c1-c9f3bf000339@github.com>

On Wed, 7 Apr 2021 02:48:00 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding BigDecimal equivalents to tests

Marked as reviewed by rriggs (Reviewer).

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

> 3824:                 BigDecimal tenToTheNegFour = BigDecimal.valueOf(1, 4);
> 3825:                 BigDecimal tenToThePrec = BigDecimal.valueOf(1, -prec);
> 3826:                 value = value.round(new MathContext(prec));

While you are in the area, how about inlining the creation of the tenToTheNegFour and tenToThePrec values.
They are used only once and may not be used at all. They don't appear to be needed except for the comparisons.

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

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

From igraves at openjdk.java.net  Fri Apr 16 16:08:53 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 16 Apr 2021 16:08:53 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits [v3]
In-Reply-To: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
Message-ID: <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>

> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

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

  Inlining some single use variables

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3363/files
  - new: https://git.openjdk.java.net/jdk/pull/3363/files/cf40421e..45522605

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

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

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

From igraves at openjdk.java.net  Fri Apr 16 16:14:42 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 16 Apr 2021 16:14:42 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits [v2]
In-Reply-To: <GhkZVYo0g3PkRg-ZYddWBne9V_cxU6nhm0jkWOssUoA=.9b5476b9-2261-42a3-90c1-c9f3bf000339@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <O2mswzonqSXwR182cYYrlA7-lRwGnOCUav_bpVD5EjE=.4f6b2e1c-8fdc-4455-b561-1892804e1788@github.com>
 <GhkZVYo0g3PkRg-ZYddWBne9V_cxU6nhm0jkWOssUoA=.9b5476b9-2261-42a3-90c1-c9f3bf000339@github.com>
Message-ID: <_kz15G9r7nsrbUDy8Si6xTDnot4S-IjzaygMQYaPQ_w=.d702a819-1ff2-4be3-a040-a077c7c2f2b1@github.com>

On Fri, 16 Apr 2021 14:26:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding BigDecimal equivalents to tests
>
> src/java.base/share/classes/java/util/Formatter.java line 3826:
> 
>> 3824:                 BigDecimal tenToTheNegFour = BigDecimal.valueOf(1, 4);
>> 3825:                 BigDecimal tenToThePrec = BigDecimal.valueOf(1, -prec);
>> 3826:                 value = value.round(new MathContext(prec));
> 
> While you are in the area, how about inlining the creation of the tenToTheNegFour and tenToThePrec values.
> They are used only once and may not be used at all. They don't appear to be needed except for the comparisons.

Makes sense to me.

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

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

From bpb at openjdk.java.net  Fri Apr 16 17:36:37 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 16 Apr 2021 17:36:37 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits [v3]
In-Reply-To: <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
Message-ID: <aVEiCZJtHi7y8nMjUyrFxtpdAY3KQilN_imD0biX9p4=.27dc635b-868e-45aa-b9a6-4a3476130cc8@github.com>

On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inlining some single use variables

I think this looks all right. I assume you ran all the `java.math` tests.

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

Marked as reviewed by bpb (Reviewer).

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

From igraves at openjdk.java.net  Fri Apr 16 19:50:36 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 16 Apr 2021 19:50:36 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits [v3]
In-Reply-To: <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
Message-ID: <hYcI1pxic8Rubb1tBu18L-vF2PpIplAO2hYpZ_22_sI=.ef69e1dd-fb72-4554-96e8-0fc1dd7ea896@github.com>

On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inlining some single use variables

That's correct. Passes `java.math` tests. Ran it again, just to be sure.

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

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

From igraves at openjdk.java.net  Fri Apr 16 20:08:39 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 16 Apr 2021 20:08:39 GMT
Subject: <i18n dev> Integrated: 8262744: Formatter '%g' conversion uses
 wrong format for BigDecimal rounding up to limits
In-Reply-To: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
Message-ID: <-dcdAT5JQH7sVtoVVNWqJuz8T4-JYBda9FM-EOc25bE=.376e7b4d-1c05-4b18-9b0b-2e823dd7988c@github.com>

On Tue, 6 Apr 2021 20:34:52 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.

This pull request has now been integrated.

Changeset: 0bdc3e7a
Author:    Ian Graves <igraves at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0bdc3e7a
Stats:     66 lines in 2 files changed: 62 ins; 1 del; 3 mod

8262744: Formatter '%g' conversion uses wrong format for BigDecimal rounding up to limits

Reviewed-by: rriggs, bpb

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

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

From naoto at openjdk.java.net  Fri Apr 16 21:16:59 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 21:16:59 GMT
Subject: <i18n dev> RFR: 8265375: Bootcycle builds fail with
 StackOverflowError in cldrconverter
Message-ID: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>

Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`).

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

Commit messages:
 - 8265375: Bootcycle builds fail with StackOverflowError in cldrconverter

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

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

From joehw at openjdk.java.net  Fri Apr 16 21:29:34 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 16 Apr 2021 21:29:34 GMT
Subject: <i18n dev> RFR: 8265375: Bootcycle builds fail with
 StackOverflowError in cldrconverter
In-Reply-To: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
References: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
Message-ID: <6UEEUmoNYsRc6LSvDR8Nr2wwPQHbZg9iYFS8TZYqONk=.9e5fc2ca-88e9-4dd8-9ace-4a35fd795625@github.com>

On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`).

Marked as reviewed by joehw (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Apr 16 22:20:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 22:20:08 GMT
Subject: <i18n dev> RFR: 8265375: Bootcycle builds fail with
 StackOverflowError in cldrconverter [v2]
In-Reply-To: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
References: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
Message-ID: <Ng67_896c_coTkheMM9hJagLoZOsYLdt5nizD60L3Hw=.227f8fde-54ce-4fbb-865d-c93c295c179b@github.com>

> Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`).

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

  Copyright year update.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3553/files
  - new: https://git.openjdk.java.net/jdk/pull/3553/files/91326786..e54cb6ec

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

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

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

From naoto at openjdk.java.net  Fri Apr 16 22:26:46 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 16 Apr 2021 22:26:46 GMT
Subject: <i18n dev> Integrated: 8265375: Bootcycle builds fail with
 StackOverflowError in cldrconverter
In-Reply-To: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
References: <lBfzrD7CvaJ9fFJ_BS3z3PI86LBSAVXsCP6tpXPJTXg=.404f216d-c462-4472-bb5d-277fa234b798@github.com>
Message-ID: <5VUdiDhBm9E-XcRwHzd0K7gntyW0r0KfKbzUk01XoGU=.fbd8772f-b00c-4bc5-8ca8-4f0024679bb0@github.com>

On Fri, 16 Apr 2021 21:10:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the tier4 build failure. The piece of code that made into `CLDRLocaleProviderAdapter.java` was also needed in the build tool counterpart (`CLDRConverter`).

This pull request has now been integrated.

Changeset: ff499701
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff499701
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8265375: Bootcycle builds fail with StackOverflowError in cldrconverter

Reviewed-by: joehw

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

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

From pconcannon at openjdk.java.net  Mon Apr 19 10:38:17 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 19 Apr 2021 10:38:17 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v4]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <qcPDAqnJlx0EAJiNJ6cArn0SfaKleRNq8uTGVyJ8p40=.f2acc1ab-96e0-41f4-b8f0-941757fb08b7@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 six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 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/d7355049..6481346a

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

  Stats: 69174 lines in 1873 files changed: 32339 ins; 31989 del; 4846 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 rriggs at openjdk.java.net  Mon Apr 19 15:50:44 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 19 Apr 2021 15:50:44 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v4]
In-Reply-To: <qcPDAqnJlx0EAJiNJ6cArn0SfaKleRNq8uTGVyJ8p40=.f2acc1ab-96e0-41f4-b8f0-941757fb08b7@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <qcPDAqnJlx0EAJiNJ6cArn0SfaKleRNq8uTGVyJ8p40=.f2acc1ab-96e0-41f4-b8f0-941757fb08b7@github.com>
Message-ID: <5fRAroNJRKwOzQ_i7zcWDkDYJ2xcIVB-4p1tDtTHgKQ=.c82afb9a-d0a7-4915-a3f4-e1958253bb68@github.com>

On Mon, 19 Apr 2021 10:38:17 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
>
> 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 six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 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

I generally concur with `forax` about avoiding the use of single letter variables.

src/java.base/share/classes/java/time/Duration.java line 1435:

> 1433:                 && this.seconds == other.seconds
> 1434:                 && this.nanos == other.nanos;
> 1435:     }

Perhaps rename the argument and use `otherDuration` as the refinement.
Otherwise, an inconsistency across various classes will creep in where the more specific variable has a more general name.  In this case, the argument type is Object, so the argument name `otherDuration` is not strictly true.

src/java.base/share/classes/java/time/Instant.java line 1306:

> 1304:                 && this.seconds == other.seconds
> 1305:                 && this.nanos == other.nanos;
> 1306:     }

Ditto, `otherInstance` is not strictly always an instant and it would be more consistent to swap the names.
`(other instanceof Instant otherInstant)`.

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

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

From pconcannon at openjdk.java.net  Tue Apr 20 15:35:40 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 15:35:40 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v5]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <Nw3mk6ouTa6ti4a4OetqMNdBit3OgIjuXQna6zeq0Cw=.71e62d26-5bfe-45a5-b5ac-01e56efc095c@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 seven additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 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/6481346a..2dca4a09

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

  Stats: 3821 lines in 79 files changed: 2021 ins; 1604 del; 196 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 pconcannon at openjdk.java.net  Tue Apr 20 17:38:07 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 17:38:07 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v5]
In-Reply-To: <wnSAgogvub7uNdnY8-w7gtbWP_G7_Fmto3S2yxFQWm0=.fbc2ded4-61d4-4340-b142-c63c0f673a48@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <wnSAgogvub7uNdnY8-w7gtbWP_G7_Fmto3S2yxFQWm0=.fbc2ded4-61d4-4340-b142-c63c0f673a48@github.com>
Message-ID: <bG1E9ja_MbcdHydLK1by-ykObZkeWDWvglMcEHvZTZI=.9ecbd890-6ad2-4ca1-b00c-e52ab06f7a6b@github.com>

On Wed, 24 Mar 2021 13:57:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

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

Hi Roger, I plan to introduce switch expressions in a follow up issue/PR.

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

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

From pconcannon at openjdk.java.net  Tue Apr 20 17:46:46 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 17:46:46 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v4]
In-Reply-To: <5fRAroNJRKwOzQ_i7zcWDkDYJ2xcIVB-4p1tDtTHgKQ=.c82afb9a-d0a7-4915-a3f4-e1958253bb68@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <qcPDAqnJlx0EAJiNJ6cArn0SfaKleRNq8uTGVyJ8p40=.f2acc1ab-96e0-41f4-b8f0-941757fb08b7@github.com>
 <5fRAroNJRKwOzQ_i7zcWDkDYJ2xcIVB-4p1tDtTHgKQ=.c82afb9a-d0a7-4915-a3f4-e1958253bb68@github.com>
Message-ID: <dKayuHyBJE9eRsK4iUx1CRCTB6BOurLpF-pfTGxND8U=.9a074a36-77eb-4178-81d2-d328ed4c9700@github.com>

On Mon, 19 Apr 2021 15:37:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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 six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - 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
>
> src/java.base/share/classes/java/time/Duration.java line 1435:
> 
>> 1433:                 && this.seconds == other.seconds
>> 1434:                 && this.nanos == other.nanos;
>> 1435:     }
> 
> Perhaps rename the argument and use `otherDuration` as the refinement.
> Otherwise, an inconsistency across various classes will creep in where the more specific variable has a more general name.  In this case, the argument type is Object, so the argument name `otherDuration` is not strictly true.

Parameter and pattern variable names swapped, as suggested. See 647bd6b

> src/java.base/share/classes/java/time/Instant.java line 1306:
> 
>> 1304:                 && this.seconds == other.seconds
>> 1305:                 && this.nanos == other.nanos;
>> 1306:     }
> 
> Ditto, `otherInstance` is not strictly always an instant and it would be more consistent to swap the names.
> `(other instanceof Instant otherInstant)`.

Parameter and pattern variable names swapped, as suggested. See 647bd6b

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

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

From pconcannon at openjdk.java.net  Tue Apr 20 17:46:38 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 17:46:38 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v6]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@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 incrementally with one additional commit since the last revision:

  Updated single letter pattern variable names

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/2dca4a09..647bd6b1

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

  Stats: 51 lines in 14 files changed: 0 ins; 0 del; 51 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 pconcannon at openjdk.java.net  Tue Apr 20 17:46:49 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 20 Apr 2021 17:46:49 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v6]
In-Reply-To: <Dpzk0f63E8tPAC1zjmQ29kGopHHsyjozKI3AP_EpWCg=.079e6cda-ad0f-4b80-a254-5b3f2888a2eb@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <Dpzk0f63E8tPAC1zjmQ29kGopHHsyjozKI3AP_EpWCg=.079e6cda-ad0f-4b80-a254-5b3f2888a2eb@github.com>
Message-ID: <ALVe6r-PBZ4etyOYsM3aqIcOj3GFjP8cursdSAWm89k=.975f052a-4852-4531-8543-d627216b311d@github.com>

On Wed, 24 Mar 2021 10:57:11 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated single letter pattern variable names
>
> 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`

Thanks for your comments, @forax, and apologizes for the delay in getting back to you. I was waiting for the boot JDK version to be updated to 16. Certain files changed in the PR are shared between the build tool and the JDK runtime, and were causing build issues.
I've addressed the changes you suggested, and you can find them in commit 647bd6b

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

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

From rriggs at openjdk.java.net  Tue Apr 20 19:58:12 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 20 Apr 2021 19:58:12 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v6]
In-Reply-To: <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
Message-ID: <XnnEo4lzumJLSiGui7nFG7kxpQT4z2z1d-ekLhKbiz8=.57737046-9ebe-4024-99ba-5ea05dab20c0@github.com>

On Tue, 20 Apr 2021 17:46:38 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
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated single letter pattern variable names

Marked as reviewed by rriggs (Reviewer).

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

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

From naoto at openjdk.java.net  Tue Apr 20 21:19:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 20 Apr 2021 21:19:08 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v6]
In-Reply-To: <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
Message-ID: <ISBMUHz11kgI1vyd6c8RNYuUSGsioi4U57QN5xFLzbw=.82fbc316-f714-4888-b618-feb8702b39aa@github.com>

On Tue, 20 Apr 2021 17:46:38 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
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated single letter pattern variable names

Marked as reviewed by naoto (Reviewer).

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

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

From smarks at openjdk.java.net  Wed Apr 21 02:23:09 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 21 Apr 2021 02:23:09 GMT
Subject: <i18n dev> RFR: 8262744: Formatter '%g' conversion uses wrong
 format for BigDecimal rounding up to limits [v3]
In-Reply-To: <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
References: <-lkz4ey1lYtRvoNAa8Teva5ogrxtx-vNZyZudlzz7t0=.3adeb732-e7b6-494c-9a9e-1695d1a80c74@github.com>
 <Na9CS40dfnXuwcAf6zTz53ghP0EY27Wt_i8voN3k1rQ=.8d455c0b-ec54-4a81-9aba-bdc102022ac9@github.com>
Message-ID: <_elqbinfPX1hdlCpOW7qas6U9NsqcusGkz9sQvyUOQ4=.a0d00170-863e-4422-be00-c5fdb76228b5@github.com>

On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a bug where the formatting code for `%g` flags incorrectly tries to round `BigDecimal` after determining whether it should be a decimal numeric format or a scientific numeric format. The solution rounds before determining the correct format.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inlining some single use variables

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

> 3825:                 if ((value.equals(BigDecimal.ZERO))
> 3826:                     || ((value.compareTo(BigDecimal.valueOf(1, 4)) != -1)
> 3827:                         && (value.compareTo(BigDecimal.valueOf(1, -prec)) == -1))) {

Note that `compareTo` in general specifies a negative, zero, or positive return value, but BigDecimal and BigInteger specify a return value of -1, 0, and 1. So the code here that compares against -1 is strictly correct. However, the BigDecimal/BigInteger.compareTo docs say "The suggested idiom..." is a relative comparison against zero.

Indeed, the BigDecimal::compareTo method does always seem to return -1, 0, or 1 so this code is not incorrect. Well, maybe. I checked quickly and the BigDecimal comparison logic is fairly intricate (and also runs through BigInteger) so I might have missed something. Also, BigDecimal is subclassable, so an override of `compareTo` might return something other than -1, 0, or 1, even though strictly speaking this would violate the BigDecimal spec.

I'm wondering if there should be a followup bug that changes these tests to `>= 0` and `< 0`.

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

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

From dfuchs at openjdk.java.net  Wed Apr 21 09:24:17 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 21 Apr 2021 09:24:17 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v6]
In-Reply-To: <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
Message-ID: <HuY_a_SFC1Pliway8FqR3KnJ2ek8Ar91Cxi4BTK7SsY=.35fb7617-312c-412a-910b-37bd87d82989@github.com>

On Tue, 20 Apr 2021 17:46:38 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
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated single letter pattern variable names

src/java.base/share/classes/java/time/Duration.java line 723:

> 721:         }
> 722:         if (unit instanceof ChronoUnit u) {
> 723:             switch (u) {

Maybe `u` could be replaced with `chronoUnit` here too

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

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

From pconcannon at openjdk.java.net  Wed Apr 21 10:58:34 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Apr 2021 10:58:34 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v6]
In-Reply-To: <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>
Message-ID: <4TBFMGUFpV1Gf3TmyGUds5mX37fnWQyB07ar6CttkNc=.f174f0f6-639b-402d-88fe-7e4a50f9f678@github.com>

On Wed, 24 Mar 2021 11:06:38 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated single letter pattern variable names
>
> 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`

Updated in 647bd6b as suggested by Michael Kuhlmann

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

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

From pconcannon at openjdk.java.net  Wed Apr 21 11:06:16 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Apr 2021 11:06:16 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@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 10 additional commits since the last revision:

 - Updated single letter pattern variable name in java/time/Duration
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Updated single letter pattern variable names
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 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/647bd6b1..3dc1e075

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

  Stats: 2549 lines in 111 files changed: 1748 ins; 362 del; 439 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 pconcannon at openjdk.java.net  Wed Apr 21 11:06:20 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Apr 2021 11:06:20 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v6]
In-Reply-To: <HuY_a_SFC1Pliway8FqR3KnJ2ek8Ar91Cxi4BTK7SsY=.35fb7617-312c-412a-910b-37bd87d82989@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <97NJ4-aOu-jdUmV1SW9Fmn2CDv1wedphcJdL9j3v6MM=.405164a0-e99e-49ae-94cb-6f2fdddf3a0f@github.com>
 <HuY_a_SFC1Pliway8FqR3KnJ2ek8Ar91Cxi4BTK7SsY=.35fb7617-312c-412a-910b-37bd87d82989@github.com>
Message-ID: <jVlhvbqiGQxIenMfpUU2dCFbGlPgp38G_C72N06pxR4=.0ff1ef12-c7ce-4b2b-abe5-2701873dacbe@github.com>

On Wed, 21 Apr 2021 09:06:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated single letter pattern variable names
>
> src/java.base/share/classes/java/time/Duration.java line 723:
> 
>> 721:         }
>> 722:         if (unit instanceof ChronoUnit u) {
>> 723:             switch (u) {
> 
> Maybe `u` could be replaced with `chronoUnit` here too

Variable name updated as suggested in 3dc1e07

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

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

From dfuchs at openjdk.java.net  Wed Apr 21 11:42:41 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 21 Apr 2021 11:42:41 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <aAPU384PiHRK7tcpVWx1U80gImlldjmdwWf9ORr60kc=.33edb9c4-e542-4011-b35c-034284a0a4c6@github.com>

On Wed, 21 Apr 2021 11:06: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
>
> 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 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 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

Marked as reviewed by dfuchs (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Apr 21 13:04:36 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 21 Apr 2021 13:04:36 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>

On Wed, 21 Apr 2021 11:06: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
>
> 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 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 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

I was able to find (with IntelliJ IDEA help) few more places to improve

    java.time   27 warnings 
        class Clock   2 warnings 
            class FixedClock   1 warning 
                method equals(Object)   1 warning 
                    WARNING Variable 'other' can be replaced with pattern variable 
            class OffsetClock   1 warning 
                method equals(Object)   1 warning 
                    WARNING Variable 'other' can be replaced with pattern variable 
        class Instant   2 warnings 
            method until(Temporal, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class LocalDate   5 warnings 
            method minus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
            method plus(long, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method plus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToAdd' can be replaced with pattern variable 
            method range(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class LocalDateTime   8 warnings 
            method get(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method getLong(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method isSupported(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method minus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
            method plus(long, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method plus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToAdd' can be replaced with pattern variable 
            method range(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class LocalTime   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class OffsetDateTime   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class Year   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class YearMonth   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class ZonedDateTime   6 warnings 
            method equals(Object)   1 warning 
                WARNING Variable 'other' can be replaced with pattern variable 
            method minus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
            method plus(TemporalAmount)   1 warning 
                WARNING Variable 'periodToAdd' can be replaced with pattern variable 
            method with(TemporalAdjuster)   2 warnings 
                WARNING Variable 'odt' can be replaced with pattern variable 
                WARNING Variable 'instant' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
    java.time.chrono   13 warnings 
        class ChronoLocalDateImpl   1 warning 
            method plus(long, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class ChronoLocalDateTimeImpl   6 warnings 
            method get(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method getLong(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method isSupported(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method plus(long, TemporalUnit)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method range(TemporalField)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class ChronoPeriodImpl   1 warning 
            method validateAmount(TemporalAmount)   1 warning 
                WARNING Variable 'period' can be replaced with pattern variable 
        class ChronoZonedDateTimeImpl   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class HijrahDate   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class JapaneseDate   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class MinguoDate   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
        class ThaiBuddhistDate   1 warning 
            method with(TemporalField, long)   1 warning 
                WARNING Variable 'f' can be replaced with pattern variable 
    java.time.format   3 warnings 
        class DecimalStyle   1 warning 
            method equals(Object)   1 warning 
                WARNING Variable 'other' can be replaced with pattern variable 
        class Parsed   2 warnings 
            method resolveFields()   2 warnings 
                WARNING Variable 'czdt' can be replaced with pattern variable 
                WARNING Variable 'cldt' can be replaced with pattern variable 
    java.time.zone   1 warning 
        class TzdbZoneRulesProvider   1 warning 
            method provideRules(String, boolean)   1 warning 
                WARNING Variable 'bytes' can be replaced with pattern variable 

Do you have plans to adjust them too?

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

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

From duke at openjdk.java.net  Wed Apr 21 13:38:41 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 21 Apr 2021 13:38:41 GMT
Subject: <i18n dev> Withdrawn: 8257733: Move module-specific data from make
 to respective module
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <pDP5xeFMzByh8WRd5O5mePAKLL8iQl1fsbrjzbOz-AQ=.ce5414cf-66ca-4c58-b49e-4e52df238b71@github.com>

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [x] java.desktop
> - [x] jdk.compiler
> - [x] java.se

This pull request has been closed without being integrated.

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

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

From rriggs at openjdk.java.net  Wed Apr 21 14:13:37 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 21 Apr 2021 14:13:37 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <Owozh-k2ldLp4iB1sNOo-ExOtPg8icaSENwW_fMF4vs=.7c7d9591-4c70-4c1d-8a52-1e919416039b@github.com>

On Wed, 21 Apr 2021 11:06: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
>
> 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 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 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

Marked as reviewed by rriggs (Reviewer).

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

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

From pconcannon at openjdk.java.net  Wed Apr 21 14:37:37 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 21 Apr 2021 14:37:37 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
 <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
Message-ID: <qt4ydRX6jyAGi4BhIh4NDH_6hOaTclEbeiAusq3ociI=.9f3f206d-bd62-451c-9774-42914d86b8ab@github.com>

On Wed, 21 Apr 2021 13:02:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I was able to find (with IntelliJ IDEA help) few more places to improve
> 
> ```
>     java.time   27 warnings 
>         class Clock   2 warnings 
>             class FixedClock   1 warning 
>                 method equals(Object)   1 warning 
>                     WARNING Variable 'other' can be replaced with pattern variable 
>             class OffsetClock   1 warning 
>                 method equals(Object)   1 warning 
>                     WARNING Variable 'other' can be replaced with pattern variable 
>         class Instant   2 warnings 
>             method until(Temporal, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalDate   5 warnings 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalDateTime   8 warnings 
>             method get(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method getLong(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method isSupported(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalTime   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class OffsetDateTime   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class Year   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class YearMonth   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ZonedDateTime   6 warnings 
>             method equals(Object)   1 warning 
>                 WARNING Variable 'other' can be replaced with pattern variable 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method with(TemporalAdjuster)   2 warnings 
>                 WARNING Variable 'odt' can be replaced with pattern variable 
>                 WARNING Variable 'instant' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>     java.time.chrono   13 warnings 
>         class ChronoLocalDateImpl   1 warning 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ChronoLocalDateTimeImpl   6 warnings 
>             method get(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method getLong(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method isSupported(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ChronoPeriodImpl   1 warning 
>             method validateAmount(TemporalAmount)   1 warning 
>                 WARNING Variable 'period' can be replaced with pattern variable 
>         class ChronoZonedDateTimeImpl   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class HijrahDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class JapaneseDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class MinguoDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ThaiBuddhistDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>     java.time.format   3 warnings 
>         class DecimalStyle   1 warning 
>             method equals(Object)   1 warning 
>                 WARNING Variable 'other' can be replaced with pattern variable 
>         class Parsed   2 warnings 
>             method resolveFields()   2 warnings 
>                 WARNING Variable 'czdt' can be replaced with pattern variable 
>                 WARNING Variable 'cldt' can be replaced with pattern variable 
>     java.time.zone   1 warning 
>         class TzdbZoneRulesProvider   1 warning 
>             method provideRules(String, boolean)   1 warning 
>                 WARNING Variable 'bytes' can be replaced with pattern variable 
> ```
> 
> Do you have plans to adjust them too?

Hi @turbanoff, thanks for finding these. Will take a look shortly!

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

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

From scolebourne at openjdk.java.net  Wed Apr 21 15:06:38 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 21 Apr 2021 15:06:38 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <LLSYYGCT-Pk_vgJczrWs8PxurUz2ogf6E5pMtldA1OA=.77cb7c98-6382-42fe-9568-6f7d78a3f261@github.com>

On Wed, 21 Apr 2021 11:06: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
>
> 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 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 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

Marked as reviewed by scolebourne (Author).

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

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

From naoto at openjdk.java.net  Wed Apr 21 15:30:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Apr 2021 15:30:40 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <2gU2LhTY7XSoyzaNjLa7NWDWsZ-EJHYlQ-vpwoLg9Jk=.ba87d778-be86-44b8-a20b-d47e457ae389@github.com>

On Wed, 21 Apr 2021 11:06: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
>
> 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 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 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

Marked as reviewed by naoto (Reviewer).

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

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

From chegar at openjdk.java.net  Wed Apr 21 15:41:40 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 21 Apr 2021 15:41:40 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
Message-ID: <mlfuFl9YvwTdMkyEHFDLEyaRfXIlI3V8M6ZbNe4J9xs=.631d2bd4-6706-4d67-ab6e-4d7a46f48dc8@github.com>

On Wed, 21 Apr 2021 11:06: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
>
> 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 10 additional commits since the last revision:
> 
>  - Updated single letter pattern variable name in java/time/Duration
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Updated single letter pattern variable names
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>  - 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

Marked as reviewed by chegar (Reviewer).

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

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

From pconcannon at openjdk.java.net  Thu Apr 22 10:21:07 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 22 Apr 2021 10:21:07 GMT
Subject: <i18n dev> Integrated: 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: <hLGmqexizmUamOI7ZrTe3AeeioAXu3Ql7KAhYnz2jxI=.2672c833-26c2-49ed-97bf-0d509422753e@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

This pull request has now been integrated.

Changeset: 28af31db
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/28af31db
Stats:     176 lines in 34 files changed: 0 ins; 47 del; 129 mod

8263668: Update java.time to use instanceof pattern variable

Reviewed-by: lancea, ryadav, naoto, rriggs, dfuchs, scolebourne, chegar

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

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

From pconcannon at openjdk.java.net  Thu Apr 22 10:21:02 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 22 Apr 2021 10:21:02 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v8]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <teAMJj4QvpxnpoenobR1PrYcWJz75mmZkX00McRCZUM=.e4a2b799-1d71-4a59-95f5-8555fa67f9f2@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 12 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Updated single letter pattern variable name in java/time/Duration
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Updated single letter pattern variable names
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/88c33d40...db6e9bb7

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/3dc1e075..db6e9bb7

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

  Stats: 522 lines in 75 files changed: 254 ins; 160 del; 108 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 pconcannon at openjdk.java.net  Thu Apr 22 10:21:06 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 22 Apr 2021 10:21:06 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
 <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
Message-ID: <iwTyLcKd5oHsec1Wmj1TfsSUb9EsC8aLSAKtN8LRucc=.74f15679-4785-48f8-8c1a-8b6e6e8b2e10@github.com>

On Wed, 21 Apr 2021 13:02:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 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 10 additional commits since the last revision:
>> 
>>  - Updated single letter pattern variable name in java/time/Duration
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Updated single letter pattern variable names
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - Merge remote-tracking branch 'origin/master' into JDK-8263668
>>  - 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
>
> I was able to find (with IntelliJ IDEA help) few more places to improve
> 
>     java.time   27 warnings 
>         class Clock   2 warnings 
>             class FixedClock   1 warning 
>                 method equals(Object)   1 warning 
>                     WARNING Variable 'other' can be replaced with pattern variable 
>             class OffsetClock   1 warning 
>                 method equals(Object)   1 warning 
>                     WARNING Variable 'other' can be replaced with pattern variable 
>         class Instant   2 warnings 
>             method until(Temporal, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalDate   5 warnings 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalDateTime   8 warnings 
>             method get(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method getLong(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method isSupported(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class LocalTime   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class OffsetDateTime   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class Year   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class YearMonth   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ZonedDateTime   6 warnings 
>             method equals(Object)   1 warning 
>                 WARNING Variable 'other' can be replaced with pattern variable 
>             method minus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>             method plus(TemporalAmount)   1 warning 
>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>             method with(TemporalAdjuster)   2 warnings 
>                 WARNING Variable 'odt' can be replaced with pattern variable 
>                 WARNING Variable 'instant' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>     java.time.chrono   13 warnings 
>         class ChronoLocalDateImpl   1 warning 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ChronoLocalDateTimeImpl   6 warnings 
>             method get(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method getLong(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method isSupported(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method plus(long, TemporalUnit)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method range(TemporalField)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ChronoPeriodImpl   1 warning 
>             method validateAmount(TemporalAmount)   1 warning 
>                 WARNING Variable 'period' can be replaced with pattern variable 
>         class ChronoZonedDateTimeImpl   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class HijrahDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class JapaneseDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class MinguoDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>         class ThaiBuddhistDate   1 warning 
>             method with(TemporalField, long)   1 warning 
>                 WARNING Variable 'f' can be replaced with pattern variable 
>     java.time.format   3 warnings 
>         class DecimalStyle   1 warning 
>             method equals(Object)   1 warning 
>                 WARNING Variable 'other' can be replaced with pattern variable 
>         class Parsed   2 warnings 
>             method resolveFields()   2 warnings 
>                 WARNING Variable 'czdt' can be replaced with pattern variable 
>                 WARNING Variable 'cldt' can be replaced with pattern variable 
>     java.time.zone   1 warning 
>         class TzdbZoneRulesProvider   1 warning 
>             method provideRules(String, boolean)   1 warning 
>                 WARNING Variable 'bytes' can be replaced with pattern variable 
> 
> Do you have plans to adjust them too?

> Hi @turbanoff, thanks for finding these. Will take a look shortly!

As this PR is already quite large, I will create a second issue to track these further changes. Thanks again for your help

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

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

From github.com+18174180+yassinhajaj at openjdk.java.net  Thu Apr 22 20:44:27 2021
From: github.com+18174180+yassinhajaj at openjdk.java.net (YassinHajaj)
Date: Thu, 22 Apr 2021 20:44:27 GMT
Subject: <i18n dev> RFR: 8263668: Update java.time to use instanceof
 pattern variable [v7]
In-Reply-To: <iwTyLcKd5oHsec1Wmj1TfsSUb9EsC8aLSAKtN8LRucc=.74f15679-4785-48f8-8c1a-8b6e6e8b2e10@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <cge2_y5lMoHH3RtSMxfZ0CEHm19yt9G226P0buJZc8E=.0267d4df-e574-4753-b3de-ed044f681807@github.com>
 <CPtJPtXV9j9BO0QmdiUyxCWJkTq4bBab9XEJlKbwdRo=.ae3a84da-8085-4cd7-bc61-fdf35d4d68b3@github.com>
 <iwTyLcKd5oHsec1Wmj1TfsSUb9EsC8aLSAKtN8LRucc=.74f15679-4785-48f8-8c1a-8b6e6e8b2e10@github.com>
Message-ID: <sd3WpwIiOQihXieLKLZYVhV3PFhZvlGqF8okqc_YPoc=.1ffd4290-c716-4df6-bdac-ad42d713a113@github.com>

On Thu, 22 Apr 2021 10:13:32 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> I was able to find (with IntelliJ IDEA help) few more places to improve
>> 
>>     java.time   27 warnings 
>>         class Clock   2 warnings 
>>             class FixedClock   1 warning 
>>                 method equals(Object)   1 warning 
>>                     WARNING Variable 'other' can be replaced with pattern variable 
>>             class OffsetClock   1 warning 
>>                 method equals(Object)   1 warning 
>>                     WARNING Variable 'other' can be replaced with pattern variable 
>>         class Instant   2 warnings 
>>             method until(Temporal, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class LocalDate   5 warnings 
>>             method minus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>>             method plus(long, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method plus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>>             method range(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class LocalDateTime   8 warnings 
>>             method get(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method getLong(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method isSupported(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method minus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>>             method plus(long, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method plus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>>             method range(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class LocalTime   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class OffsetDateTime   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class Year   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class YearMonth   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class ZonedDateTime   6 warnings 
>>             method equals(Object)   1 warning 
>>                 WARNING Variable 'other' can be replaced with pattern variable 
>>             method minus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToSubtract' can be replaced with pattern variable 
>>             method plus(TemporalAmount)   1 warning 
>>                 WARNING Variable 'periodToAdd' can be replaced with pattern variable 
>>             method with(TemporalAdjuster)   2 warnings 
>>                 WARNING Variable 'odt' can be replaced with pattern variable 
>>                 WARNING Variable 'instant' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>     java.time.chrono   13 warnings 
>>         class ChronoLocalDateImpl   1 warning 
>>             method plus(long, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class ChronoLocalDateTimeImpl   6 warnings 
>>             method get(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method getLong(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method isSupported(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method plus(long, TemporalUnit)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method range(TemporalField)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class ChronoPeriodImpl   1 warning 
>>             method validateAmount(TemporalAmount)   1 warning 
>>                 WARNING Variable 'period' can be replaced with pattern variable 
>>         class ChronoZonedDateTimeImpl   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class HijrahDate   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class JapaneseDate   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class MinguoDate   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>         class ThaiBuddhistDate   1 warning 
>>             method with(TemporalField, long)   1 warning 
>>                 WARNING Variable 'f' can be replaced with pattern variable 
>>     java.time.format   3 warnings 
>>         class DecimalStyle   1 warning 
>>             method equals(Object)   1 warning 
>>                 WARNING Variable 'other' can be replaced with pattern variable 
>>         class Parsed   2 warnings 
>>             method resolveFields()   2 warnings 
>>                 WARNING Variable 'czdt' can be replaced with pattern variable 
>>                 WARNING Variable 'cldt' can be replaced with pattern variable 
>>     java.time.zone   1 warning 
>>         class TzdbZoneRulesProvider   1 warning 
>>             method provideRules(String, boolean)   1 warning 
>>                 WARNING Variable 'bytes' can be replaced with pattern variable 
>> 
>> Do you have plans to adjust them too?
>
>> Hi @turbanoff, thanks for finding these. Will take a look shortly!
> 
> As this PR is already quite large, I will create a second issue to track these further changes. Thanks again for your help

Hi @pconcannon , good job !

However, is there a reason why you're not using `chronoUnit` in `LocalDateTime:1687` ?


    @Override
    public long until(Temporal endExclusive, TemporalUnit unit) {
        LocalDateTime end = LocalDateTime.from(endExclusive);
        if (unit instanceof ChronoUnit chronoUnit) {
            if (unit.isTimeBased()) { <-- HERE
                long amount = date.daysUntil(end.date);

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

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

From pconcannon at openjdk.java.net  Fri Apr 23 10:49:40 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 23 Apr 2021 10:49:40 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof pattern
 variable (part II)
Message-ID: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>

Hi,

Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?

This PR was split into two parts due to the large number of files affected.

Kind regards,

Patrick

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

Commit messages:
 - 8265746: Update java.time to use instanceof pattern variable (part II)

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

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

From dfuchs at openjdk.java.net  Fri Apr 23 11:00:31 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Apr 2021 11:00:31 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <oMqd9uG4qIwI92kNWhuMv1i0AWx1VJVbDo3dWeXai8g=.f4a0bb23-62c4-4835-994c-efe0c63b9cf0@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

LGTM!

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

Marked as reviewed by dfuchs (Reviewer).

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

From lancea at openjdk.java.net  Fri Apr 23 11:12:33 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 23 Apr 2021 11:12:33 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <-1CxVPydMSiKTyd274URT4xzMlfa-KLiyr5J52aqUKM=.99488ec2-f770-4657-a62b-6dfc7cfc8854@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Looks good.  Thank you for the updates

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

Marked as reviewed by lancea (Reviewer).

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

From rriggs at openjdk.java.net  Fri Apr 23 13:35:33 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 23 Apr 2021 13:35:33 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <IPetXjlloeaIx3PAnZFaLWNPHOE9hUPh9uaRhHjPAMM=.b5b33a59-44db-4507-aa42-f5548297c6c4@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Marked as reviewed by rriggs (Reviewer).

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

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

From chegar at openjdk.java.net  Fri Apr 23 14:34:25 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 23 Apr 2021 14:34:25 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <frmXbSglJBsqm0AYpbnD7U64zNbqwlTMHNT09HmGDUk=.7f1d7910-e335-45e4-af24-d58efdb7ea4d@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

Marked as reviewed by chegar (Reviewer).

src/java.base/share/classes/java/time/Clock.java line 623:

> 621:             return (obj instanceof FixedClock other
> 622:                     && instant.equals(other.instant)
> 623:                     && zone.equals(other.zone));

The outer set of braces is redundant.

src/java.base/share/classes/java/time/Clock.java line 673:

> 671:             return (obj instanceof OffsetClock other
> 672:                     && baseClock.equals(other.baseClock)
> 673:                     && offset.equals(other.offset));

The outer set of braces is redundant.

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

> 2189:             && dateTime.equals(other.dateTime)
> 2190:             && offset.equals(other.offset)
> 2191:             && zone.equals(other.zone));

same here.

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

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

From pconcannon at openjdk.java.net  Fri Apr 23 15:38:53 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 23 Apr 2021 15:38:53 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II) [v2]
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> 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:

 - Removed redundant braces
 - Merge remote-tracking branch 'origin/master' into JDK-8265746
 - 8265746: Update java.time to use instanceof pattern variable (part II)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3650/files
  - new: https://git.openjdk.java.net/jdk/pull/3650/files/974ccbf0..7f32ddbe

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

  Stats: 519 lines in 11 files changed: 275 ins; 177 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3650.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3650/head:pull/3650

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

From chegar at openjdk.java.net  Fri Apr 23 15:50:32 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 23 Apr 2021 15:50:32 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II) [v2]
In-Reply-To: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
Message-ID: <peAcwyy7z98-wHpFEWWk7ZeHVkXkDLvolvg8wJtfyDg=.82bbd7e0-aed2-4cbe-aa38-9e67e6aed943@github.com>

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> 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:
> 
>  - Removed redundant braces
>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>  - 8265746: Update java.time to use instanceof pattern variable (part II)

Marked as reviewed by chegar (Reviewer).

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

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

From naoto at openjdk.java.net  Fri Apr 23 16:07:24 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Apr 2021 16:07:24 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II) [v2]
In-Reply-To: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
Message-ID: <kqykhuV_Ybdiv1Llz_9jzIgcKNx_BZwxD1Aiz-bCb9w=.9f8e807b-419a-4d36-971c-62b3204dcd9b@github.com>

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> 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:
> 
>  - Removed redundant braces
>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>  - 8265746: Update java.time to use instanceof pattern variable (part II)

Marked as reviewed by naoto (Reviewer).

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

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

From rriggs at openjdk.java.net  Fri Apr 23 16:41:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 23 Apr 2021 16:41:27 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II) [v2]
In-Reply-To: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
Message-ID: <2MUSw9rrhD8ohPlIEG2YG7J9ZkFgCix7KtfdbTCkqiI=.4e181182-5837-4884-9dc7-5c3acf753923@github.com>

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> 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:
> 
>  - Removed redundant braces
>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>  - 8265746: Update java.time to use instanceof pattern variable (part II)

Marked as reviewed by rriggs (Reviewer).

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

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

From lancea at openjdk.java.net  Fri Apr 23 16:53:28 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 23 Apr 2021 16:53:28 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II) [v2]
In-Reply-To: <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <9YgXokaKvfzd-u4pbdqgyvz84JkzZ1nIYikP40vqn2Y=.e4c3c7b4-163b-44c9-bbab-b8001a5d3f2c@github.com>
Message-ID: <-FIE6L9Jy52RAQtypdFndpdrSUl1UVmhQFR8cAwHQAg=.aaa1465b-102d-43b3-b4c9-4914cc77bec2@github.com>

On Fri, 23 Apr 2021 15:38:53 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
>> 
>> This PR was split into two parts due to the large number of files affected.
>> 
>> 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:
> 
>  - Removed redundant braces
>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>  - 8265746: Update java.time to use instanceof pattern variable (part II)

Marked as reviewed by lancea (Reviewer).

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

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

From pconcannon at openjdk.java.net  Mon Apr 26 08:35:49 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 26 Apr 2021 08:35:49 GMT
Subject: <i18n dev> Integrated: 8265746: Update java.time to use instanceof
 pattern variable (part II)
In-Reply-To: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
Message-ID: <VV9tn4c66YNe6s2NhKlUrXP2pbc2YPhe7dUh5Zpv_Bw=.2802dddd-91c1-4adb-bfd3-8a7a68417b10@github.com>

On Fri, 23 Apr 2021 10:44:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of the `instanceof` pattern variable?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

This pull request has now been integrated.

Changeset: 45c5da0f
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45c5da0f
Stats:     152 lines in 20 files changed: 0 ins; 48 del; 104 mod

8265746: Update java.time to use instanceof pattern variable (part II)

Reviewed-by: dfuchs, lancea, rriggs, chegar, naoto

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

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

From pconcannon at openjdk.java.net  Mon Apr 26 08:35:48 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 26 Apr 2021 08:35:48 GMT
Subject: <i18n dev> RFR: 8265746: Update java.time to use instanceof
 pattern variable (part II) [v2]
In-Reply-To: <frmXbSglJBsqm0AYpbnD7U64zNbqwlTMHNT09HmGDUk=.7f1d7910-e335-45e4-af24-d58efdb7ea4d@github.com>
References: <STdYxBiN6b5Gz99NZ963gNT0pTP2dyyEjC594lqJ9Xk=.3d4d7d79-91e1-4f84-b589-53e06019c7dd@github.com>
 <frmXbSglJBsqm0AYpbnD7U64zNbqwlTMHNT09HmGDUk=.7f1d7910-e335-45e4-af24-d58efdb7ea4d@github.com>
Message-ID: <9Y31mmaYRt36MOa1iNUHDVRJBt3_g5i5t8EHipt1i08=.de3e1ffe-7f86-4864-97a8-04a68df51d1f@github.com>

On Fri, 23 Apr 2021 14:29:36 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> 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:
>> 
>>  - Removed redundant braces
>>  - Merge remote-tracking branch 'origin/master' into JDK-8265746
>>  - 8265746: Update java.time to use instanceof pattern variable (part II)
>
> src/java.base/share/classes/java/time/Clock.java line 623:
> 
>> 621:             return (obj instanceof FixedClock other
>> 622:                     && instant.equals(other.instant)
>> 623:                     && zone.equals(other.zone));
> 
> The outer set of braces is redundant.

Braces removed in 7f32ddb

> src/java.base/share/classes/java/time/ZonedDateTime.java line 2191:
> 
>> 2189:             && dateTime.equals(other.dateTime)
>> 2190:             && offset.equals(other.offset)
>> 2191:             && zone.equals(other.zone));
> 
> same here.

See 7f32ddb

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

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

From itakiguchi at openjdk.java.net  Tue Apr 27 16:56:58 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 27 Apr 2021 16:56:58 GMT
Subject: <i18n dev> RFR: 8266013: Unexpected replacement character handling
 on stateful CharsetEncoder
Message-ID: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>

When an invalid character is converted by getBytes() method, the character is converted to replacement byte data.
Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
EBCDIC Mix charset encoder is stateful encoder.
Shift code should be added by switching character set.
On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F"
SI is not in right place.

Also ISO2022 related charsets use escape sequence to switch character set.
But same kind of issue is there.

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

Commit messages:
 - 8266013: Unexpected replacement character handling on stateful CharsetEncoder

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

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

From igraves at openjdk.java.net  Tue Apr 27 21:41:23 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 27 Apr 2021 21:41:23 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use Stream.toList()
Message-ID: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>

8266155: Convert java.base to use Stream.toList()

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

Commit messages:
 - Migrating java.base to use Stream.toList()

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

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

From bpb at openjdk.java.net  Tue Apr 27 21:55:07 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Apr 2021 21:55:07 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use
 Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <KY3YZ9lHY0GKOEIHRvhlW2tJOj0lBScCxdTo3RG0AIo=.b713f544-110b-47b5-bf6f-7837a8ce70e2@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

Looks all right.

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

Marked as reviewed by bpb (Reviewer).

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

From naoto at openjdk.java.net  Tue Apr 27 22:00:11 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 27 Apr 2021 22:00:11 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use
 Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <D6mefFUWVpv5pnPAKmJnVPHF1Qd1zgHWCGuXZRxWxQM=.e51d43b4-f26e-422f-8b8f-ec9955bd859e@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

Marked as reviewed by naoto (Reviewer).

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

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

From iris at openjdk.java.net  Wed Apr 28 00:36:52 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Apr 2021 00:36:52 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use
 Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <ccce-pWiORe39fUtIMDRvrPZd2OuuX6ZMRcVO9eSlwc=.a90a66f5-ba60-4b8c-8cc8-76c3f1b69985@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

Marked as reviewed by iris (Reviewer).

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

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

From chegar at openjdk.java.net  Wed Apr 28 15:45:51 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 15:45:51 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use
 Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <cEXtMAY-kmVvoUJ_CTyWpa-_X9PWs4Xy2taHH-Iuf70=.18a98221-9f65-4998-a19b-c0359c7111a0@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

Marked as reviewed by chegar (Reviewer).

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6788:

> 6786:     }
> 6787: 
> 6788:     /**

I think the import of Collectors can be dropped in this file? And maybe a few other files too?

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

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

From redestad at openjdk.java.net  Wed Apr 28 15:52:13 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 28 Apr 2021 15:52:13 GMT
Subject: <i18n dev> RFR: 8264678: Incomplete comment in
 build.tools.generatecharacter.GenerateCharacter
Message-ID: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>

I'm not exactly sure what I intended to say in this partial comment. Removing it.

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

Commit messages:
 - Incomplete comment in build.tools.generatecharacter.GenerateCharacter

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

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

From erikj at openjdk.java.net  Wed Apr 28 16:00:54 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 28 Apr 2021 16:00:54 GMT
Subject: <i18n dev> RFR: 8264678: Incomplete comment in
 build.tools.generatecharacter.GenerateCharacter
In-Reply-To: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>
References: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>
Message-ID: <DM-hlDNAH6qICsVTphrpyTOkG95ABnyVpeiNGrKQAvI=.4afd2efc-13f8-4751-8477-3044d73cc33a@github.com>

On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'm not exactly sure what I intended to say in this partial comment. Removing it.

Marked as reviewed by erikj (Reviewer).

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

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

From alanb at openjdk.java.net  Wed Apr 28 16:11:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 28 Apr 2021 16:11:52 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use
 Stream.toList()
In-Reply-To: <cEXtMAY-kmVvoUJ_CTyWpa-_X9PWs4Xy2taHH-Iuf70=.18a98221-9f65-4998-a19b-c0359c7111a0@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
 <cEXtMAY-kmVvoUJ_CTyWpa-_X9PWs4Xy2taHH-Iuf70=.18a98221-9f65-4998-a19b-c0359c7111a0@github.com>
Message-ID: <uME66ILdnMw-zG9r48mdkXiWDvO4ORG8IFYYL_2aXLE=.3f41faec-818c-471c-ad70-68ca9cb2d395@github.com>

On Wed, 28 Apr 2021 15:41:31 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> 8266155: Convert java.base to use Stream.toList()
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 6788:
> 
>> 6786:     }
>> 6787: 
>> 6788:     /**
> 
> I think the import of Collectors can be dropped in this file? And maybe a few other files too?

The import can be dropped from the jdk.internal.module.* classes too.

jdk.internal.module.IllegalAccessLogger will likely be removed as part of JEP 403.

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

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

From naoto at openjdk.java.net  Wed Apr 28 16:19:53 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 28 Apr 2021 16:19:53 GMT
Subject: <i18n dev> RFR: 8264678: Incomplete comment in
 build.tools.generatecharacter.GenerateCharacter
In-Reply-To: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>
References: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>
Message-ID: <-xGo8ZUpK052EsjXyGYZoBvU8aILNrFPTEgQPSZ6tSI=.8eded174-da64-4c19-96b9-8b69fe5865e2@github.com>

On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'm not exactly sure what I intended to say in this partial comment. Removing it.

Marked as reviewed by naoto (Reviewer).

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

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

From iris at openjdk.java.net  Wed Apr 28 16:35:54 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Apr 2021 16:35:54 GMT
Subject: <i18n dev> RFR: 8264678: Incomplete comment in
 build.tools.generatecharacter.GenerateCharacter
In-Reply-To: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>
References: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>
Message-ID: <7eBURBdNl7QUFH1-qqlJwWlmdu_lOCouuLg3RaRs1Bk=.c48baad9-4a22-45fd-aeec-35089e5a748e@github.com>

On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'm not exactly sure what I intended to say in this partial comment. Removing it.

Marked as reviewed by iris (Reviewer).

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

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

From igraves at openjdk.java.net  Wed Apr 28 16:57:25 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 28 Apr 2021 16:57:25 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use
 Stream.toList() [v2]
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>

> 8266155: Convert java.base to use Stream.toList()

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

  Removing redundant imports

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3734/files
  - new: https://git.openjdk.java.net/jdk/pull/3734/files/3fb335e8..a0242a13

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

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

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

From iris at openjdk.java.net  Wed Apr 28 17:05:07 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Apr 2021 17:05:07 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use
 Stream.toList() [v2]
In-Reply-To: <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
 <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>
Message-ID: <WdZDr0c5_WI91GjcAZVbdtVXZY_iStJh3ELvPofyhlE=.bc366756-3583-43b4-b1db-be2d92aed50e@github.com>

On Wed, 28 Apr 2021 16:57:25 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8266155: Convert java.base to use Stream.toList()
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing redundant imports

Marked as reviewed by iris (Reviewer).

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

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

From chegar at openjdk.java.net  Wed Apr 28 17:27:53 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Apr 2021 17:27:53 GMT
Subject: <i18n dev> RFR: 8266155: Convert java.base to use
 Stream.toList() [v2]
In-Reply-To: <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
 <wifjSAvMAhCmXWblelooKHF-tWXjydLvERqeUPCcjUA=.bb0e36bb-1017-45ba-8457-d171741280b4@github.com>
Message-ID: <IKAxKZIh8vvmFtzCTvFNY_I6rMJykBvctlUFX6v_kvQ=.3c0446bc-34f1-478f-9309-b4cfcaea79d1@github.com>

On Wed, 28 Apr 2021 16:57:25 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8266155: Convert java.base to use Stream.toList()
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing redundant imports

Marked as reviewed by chegar (Reviewer).

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

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

From redestad at openjdk.java.net  Wed Apr 28 19:53:52 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 28 Apr 2021 19:53:52 GMT
Subject: <i18n dev> Integrated: 8264678: Incomplete comment in
 build.tools.generatecharacter.GenerateCharacter
In-Reply-To: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>
References: <8RgJUgoy411hXBbgABP3jYPHF3mchyYhx9zovYC6SWk=.0e632464-a3f1-4862-b3f0-c031f55f590f@github.com>
Message-ID: <k-Z5DrMshWCiRoy05Notfc-jPdK83AqQIevlel17xU8=.7e6f5cce-61eb-4369-9dd7-89bb9994525d@github.com>

On Wed, 28 Apr 2021 15:44:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'm not exactly sure what I intended to say in this partial comment. Removing it.

This pull request has now been integrated.

Changeset: 9df6cc7c
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9df6cc7cc2633e4231b9b69bed8a0f9e13ec74a7
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8264678: Incomplete comment in build.tools.generatecharacter.GenerateCharacter

Reviewed-by: erikj, naoto, iris

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

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

From itakiguchi at openjdk.java.net  Fri Apr 30 16:11:30 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 30 Apr 2021 16:11:30 GMT
Subject: <i18n dev> RFR: 8266013: Unexpected replacement character
 handling on stateful CharsetEncoder [v2]
In-Reply-To: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>
References: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>
Message-ID: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>

> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data.
> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
> EBCDIC Mix charset encoder is stateful encoder.
> Shift code should be added by switching character set.
> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F"
> SI is not in right place.
> 
> Also ISO2022 related charsets use escape sequence to switch character set.
> But same kind of issue is there.

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

  8266013: Unexpected replacement character handling on stateful CharsetEncoder

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3719/files
  - new: https://git.openjdk.java.net/jdk/pull/3719/files/d6a0a41b..33107e67

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

  Stats: 59 lines in 2 files changed: 40 ins; 5 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3719.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3719/head:pull/3719

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

From igraves at openjdk.java.net  Fri Apr 30 19:55:53 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 30 Apr 2021 19:55:53 GMT
Subject: <i18n dev> Integrated: 8266155: Convert java.base to use
 Stream.toList()
In-Reply-To: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
References: <bI8U1m_vU_mqrtCNufqT0vsOdRqTbED24tEoK7u-8k4=.f0120345-b866-463c-821f-aeb6974d010c@github.com>
Message-ID: <mHvLtfWQoKQB8d_mdnzBEVfdDC9E2_aUn4RxaMm_6Fk=.8a104d57-5f16-41be-bf84-e8b0a2628b1c@github.com>

On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8266155: Convert java.base to use Stream.toList()

This pull request has now been integrated.

Changeset: dd05158b
Author:    Ian Graves <igraves at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dd05158b24e8b399052a170ea9fe9ee6f65c0432
Stats:     25 lines in 8 files changed: 0 ins; 11 del; 14 mod

8266155: Convert java.base to use Stream.toList()

Reviewed-by: bpb, naoto, iris, chegar

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

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