From naoto at openjdk.java.net  Wed Sep  1 13:42:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Sep 2021 13:42:50 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux
In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
Message-ID: <EzYdLoUXV1PF46WWcsgeLoFy2E88Y8-s7I0GLRJxqfo=.f36a8bfb-e3d7-4e76-bce4-35dd893c9861@github.com>

On Wed, 1 Sep 2021 06:45:26 GMT, Wu Yan <wuyan at openjdk.org> wrote:

> Hi,
> Please help me review the change to enhance getting  time zone ID from /etc/localtime on linux.
> 
> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname.
> 
> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?.
> 
> Thanks,
> wuyan

The change looks reasonable. Please test your fix with macOS as well.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Sep  1 19:30:11 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 1 Sep 2021 19:30:11 GMT
Subject: <i18n dev> RFR: 8271603: Unnecessary Vector usage in
 java.desktop [v4]
In-Reply-To: <ZHTxa3hHOYqNUlSS9IoQJOqWbNpGr1KJ003JqowjDoc=.588a6b2c-2b9f-4aaf-8172-447c0ac16f43@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
 <NIvTAS4GZZGZaYvwtpV61lC2-9hPr5gWluKw-bVm-tc=.dfceb034-4588-40fb-893b-5a43c9d348a6@github.com>
 <dMwj1oSGORvppTPEHYHp880b9-j7CMYkPL4tQX50GTI=.1b766603-26b2-4322-979d-7c67358f7bba@github.com>
 <Mzw2vELvYDrk5ZcW0GCdifOqXb2qsXranCtQEcftif8=.67b18048-4557-4b7b-851b-443c13a8e07e@github.com>
 <ZHTxa3hHOYqNUlSS9IoQJOqWbNpGr1KJ003JqowjDoc=.588a6b2c-2b9f-4aaf-8172-447c0ac16f43@github.com>
Message-ID: <xlyPhpwj6Hvprzzoj8RMHhhZ0ex4jEwpmSldXE3ZCSo=.8d6f04b5-bdf5-4cab-bc8d-59d384ac4b38@github.com>

On Fri, 27 Aug 2021 18:28:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Can you please elaborate?
>> As I can see if size of array is exactly the same as size of vector/arraylist, implementations are similar - they just call System.arraycopy
>> ![???????????](https://user-images.githubusercontent.com/741251/131168809-480c05d6-2775-4812-91f5-c73833f9a396.png)
>
> To confirm this you need to do the same check on every usage of added toArray([]), the simpler version like "return toArray()" or return toArray(new MenuElement[elements.size()]) is simpler, no need to check something. I guess in some previouse fixes it was confirmed that the "return toArray(new MenuElement[0])" is even faster.

Ok. Simplified

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Sep  1 19:30:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 1 Sep 2021 19:30:10 GMT
Subject: <i18n dev> RFR: 8271603: Unnecessary Vector usage in
 java.desktop [v5]
In-Reply-To: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
Message-ID: <2uvW-RV4K6LMrM5QpOJF2v_FjDJVZpkj1746Q_GAY9A=.b94c87be-ebd8-4ea8-aede-cf84126a6290@github.com>

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checked only places where `Vector` was used as local variable.

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

  8271603: Unnecessary Vector usage in java.desktop
  use toArray with zero sized array in places where Vector.copyInto was used

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4680/files
  - new: https://git.openjdk.java.net/jdk/pull/4680/files/5727f6f2..1f0ebd1c

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

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Sep  1 19:46:51 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 1 Sep 2021 19:46:51 GMT
Subject: <i18n dev> RFR: 8271603: Unnecessary Vector usage in
 java.desktop [v6]
In-Reply-To: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
Message-ID: <7f4YqmkdSFHfBZVEG_zH7YlHgaXXTH946MURedTeMIs=.21591a2f-7139-49d3-a9cb-90acd423c49f@github.com>

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checked only places where `Vector` was used as local variable.

Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge remote-tracking branch 'origin/master' into avoid-unnecessary-vector-usage-in-java.desktop
   
   # Conflicts:
   #	src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java
 - 8271603: Unnecessary Vector usage in java.desktop
   use toArray with zero sized array in places where Vector.copyInto was used
 - 8271603: Unnecessary Vector usage in java.desktop
   migrate even more usages
 - 8271603: Unnecessary Vector usage in java.desktop
   migrate more usages. Not sure how I missed them
 - 8271603: Unnecessary Vector usage in java.desktop
   revert back to use cycle to copy into array
 - 8271603: Unnecessary Vector usage in java.desktop
   revert back to Enumeration
   bring back default values
 - [PATCH] Unnecessary Vector usage in java.desktop
   use zero-length array
 - [PATCH] Unnecessary Vector usage in java.desktop

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

Changes: https://git.openjdk.java.net/jdk/pull/4680/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4680&range=05
  Stats: 270 lines in 34 files changed: 19 ins; 30 del; 221 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4680.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4680/head:pull/4680

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

From wuyan at openjdk.java.net  Thu Sep  2 13:58:37 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Thu, 2 Sep 2021 13:58:37 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux
In-Reply-To: <9LFh1-fCalpsuewYw9VrvQklHPSonac2AlSQptUamf8=.1db3137e-84db-47ad-835f-cbc8719f84e0@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <9LFh1-fCalpsuewYw9VrvQklHPSonac2AlSQptUamf8=.1db3137e-84db-47ad-835f-cbc8719f84e0@github.com>
Message-ID: <lEd8XC61iygu5Bqekq7rg2jQtT1OGxY9G2xGf0Io0xc=.99c82b2d-6514-4c29-889c-9e82df0de46f@github.com>

On Wed, 1 Sep 2021 12:51:15 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> Hi,
>> Please help me review the change to enhance getting  time zone ID from /etc/localtime on linux.
>> 
>> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname.
>> 
>> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?.
>> 
>> Thanks,
>> wuyan
>
> src/java.base/unix/native/libjava/TimeZone_md.c line 292:
> 
>> 290:         /* canonicalize the path */
>> 291:         char resolvedpath[PATH_MAX + 1];
>> 292:         char *path = realpath(DEFAULT_ZONEINFO_FILE, resolvedpath);
> 
> You really should use `realpath` with `NULL` as the second argument, to avoid any risk of buffer overflow. Future C library headers may warn about non-null arguments here.

Ok, Thanks. I will refer to the implementation of `os::Posix::realpath` to fix it if we still use `realpath`. https://github.com/openjdk/jdk/blob/5245c1cf0260a78ca5f8ab4e7d13107f21faf071/src/hotspot/os/posix/os_posix.cpp#L805

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

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

From wuyan at openjdk.java.net  Thu Sep  2 13:58:36 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Thu, 2 Sep 2021 13:58:36 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux
In-Reply-To: <C0ZYlxPbz2WVGJL2aSxjV8GMQjAFvKVcPQMW3j2MLl0=.f5c32b8c-d08f-46e7-a5d1-8e44f7b24715@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <C0ZYlxPbz2WVGJL2aSxjV8GMQjAFvKVcPQMW3j2MLl0=.f5c32b8c-d08f-46e7-a5d1-8e44f7b24715@github.com>
Message-ID: <gym6lZ-di3rlDzkVq4z04Z3bvPHa5-_P9haXJMG3ofU=.752bacfa-a9ce-4384-aeab-6a7e845a0948@github.com>

On Wed, 1 Sep 2021 12:38:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I haven't come across this configuration like but changing it to use realpath seem reasonable.

Thanks, this scenario comes from our customers.

> Using `realpath` instead of `readlink` will change results on systems which use symbolic links instead of hard links to de-duplicate the timezone files. For example, on Debian, if `UTC` is configured (`/etc/localtime` points to `/usr/share/zoneinfo/UTC`), I think the result will be `Etc/UTC` instead of `UTC` after this change. But I have not actually tested this.

We tested it on ubuntu, it does have this kind of problem, thank you for your reminder. `realpath` doesn't seem to be suitable here, maybe we could directly process the previous `linkbuf` to remove the extra'.' and'/'.
> The change looks reasonable. Please test your fix with macOS as well.

Thanks, the test on macOS is passed.

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

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

From naoto at openjdk.java.net  Thu Sep  2 19:35:42 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 2 Sep 2021 19:35:42 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow Unicode
 spec for ideographs
Message-ID: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>

Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).

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

Commit messages:
 - 8273259: Character.getName doesn't follow Unicode spec for ideographs

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

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

From lancea at openjdk.java.net  Thu Sep  2 19:43:24 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 2 Sep 2021 19:43:24 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs
In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
Message-ID: <pINN1tIV0WxCQq_5o5WnV6kIsXdZdFQW5GoZKNhkGnc=.cdb957d2-3bca-487e-b23d-00538a43f0a5@github.com>

On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).

Marked as reviewed by lancea (Reviewer).

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

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

From bpb at openjdk.java.net  Thu Sep  2 19:43:24 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Sep 2021 19:43:24 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs
In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
Message-ID: <GFz6CKYEQRaxINn0yacgYXbON3etyDNK1laseOJIIbU=.37ee6f28-688f-4856-803a-524b0aa5606b@github.com>

On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).

Marked as reviewed by bpb (Reviewer).

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

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

From iris at openjdk.java.net  Thu Sep  2 22:24:26 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 2 Sep 2021 22:24:26 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs
In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
Message-ID: <xHwfSt5jla-T78N5aHAzAjYpjT56xD1wOqVuHQoY7fU=.fce23cdd-7400-4579-b16c-2f051222fba3@github.com>

On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).

Associated CSR also "Reviewed".

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

Marked as reviewed by iris (Reviewer).

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

From serb at openjdk.java.net  Fri Sep  3 03:20:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 3 Sep 2021 03:20:38 GMT
Subject: <i18n dev> RFR: 8271603: Unnecessary Vector usage in
 java.desktop [v6]
In-Reply-To: <7f4YqmkdSFHfBZVEG_zH7YlHgaXXTH946MURedTeMIs=.21591a2f-7139-49d3-a9cb-90acd423c49f@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
 <7f4YqmkdSFHfBZVEG_zH7YlHgaXXTH946MURedTeMIs=.21591a2f-7139-49d3-a9cb-90acd423c49f@github.com>
Message-ID: <m9bOeQ1dAUM6OePHF0QtwsmlcDPA33qhWHFUeFEZA1M=.810cae5f-fe23-4d94-971f-f2bad7645201@github.com>

On Wed, 1 Sep 2021 19:46:51 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
>> I checked only places where `Vector` was used as local variable.
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge remote-tracking branch 'origin/master' into avoid-unnecessary-vector-usage-in-java.desktop
>    
>    # Conflicts:
>    #	src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java
>  - 8271603: Unnecessary Vector usage in java.desktop
>    use toArray with zero sized array in places where Vector.copyInto was used
>  - 8271603: Unnecessary Vector usage in java.desktop
>    migrate even more usages
>  - 8271603: Unnecessary Vector usage in java.desktop
>    migrate more usages. Not sure how I missed them
>  - 8271603: Unnecessary Vector usage in java.desktop
>    revert back to use cycle to copy into array
>  - 8271603: Unnecessary Vector usage in java.desktop
>    revert back to Enumeration
>    bring back default values
>  - [PATCH] Unnecessary Vector usage in java.desktop
>    use zero-length array
>  - [PATCH] Unnecessary Vector usage in java.desktop

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1578:

> 1576:         }
> 1577:         String[] retValue = new String[temp.size()];
> 1578:         temp.toArray(retValue);

Why not `return temp.toArray(new String[0]);` like in other places in the last commit?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Sep  3 08:05:00 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 3 Sep 2021 08:05:00 GMT
Subject: <i18n dev> RFR: 8271603: Unnecessary Vector usage in
 java.desktop [v6]
In-Reply-To: <m9bOeQ1dAUM6OePHF0QtwsmlcDPA33qhWHFUeFEZA1M=.810cae5f-fe23-4d94-971f-f2bad7645201@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
 <7f4YqmkdSFHfBZVEG_zH7YlHgaXXTH946MURedTeMIs=.21591a2f-7139-49d3-a9cb-90acd423c49f@github.com>
 <m9bOeQ1dAUM6OePHF0QtwsmlcDPA33qhWHFUeFEZA1M=.810cae5f-fe23-4d94-971f-f2bad7645201@github.com>
Message-ID: <Du3Vniij78K5l2h8X604DRIaz8ner2Z4O98b-QsBpl0=.492ada58-1784-465b-bdcc-3b714f777425@github.com>

On Fri, 3 Sep 2021 03:17:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into avoid-unnecessary-vector-usage-in-java.desktop
>>    
>>    # Conflicts:
>>    #	src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java
>>  - 8271603: Unnecessary Vector usage in java.desktop
>>    use toArray with zero sized array in places where Vector.copyInto was used
>>  - 8271603: Unnecessary Vector usage in java.desktop
>>    migrate even more usages
>>  - 8271603: Unnecessary Vector usage in java.desktop
>>    migrate more usages. Not sure how I missed them
>>  - 8271603: Unnecessary Vector usage in java.desktop
>>    revert back to use cycle to copy into array
>>  - 8271603: Unnecessary Vector usage in java.desktop
>>    revert back to Enumeration
>>    bring back default values
>>  - [PATCH] Unnecessary Vector usage in java.desktop
>>    use zero-length array
>>  - [PATCH] Unnecessary Vector usage in java.desktop
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1578:
> 
>> 1576:         }
>> 1577:         String[] retValue = new String[temp.size()];
>> 1578:         temp.toArray(retValue);
> 
> Why not `return temp.toArray(new String[0]);` like in other places in the last commit?

Good catch! Update here too.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Sep  3 08:04:52 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 3 Sep 2021 08:04:52 GMT
Subject: <i18n dev> RFR: 8271603: Unnecessary Vector usage in
 java.desktop [v7]
In-Reply-To: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
Message-ID: <U-5c4xVAwDMZ9YOUFCwa0lbct7qJwxSVIY9lvdTvfhA=.d848f208-fa13-42d8-b823-38010d59ea19@github.com>

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checked only places where `Vector` was used as local variable.

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

  8271603: Unnecessary Vector usage in java.desktop
  one more place to call toArray with zero-sized array

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4680/files
  - new: https://git.openjdk.java.net/jdk/pull/4680/files/2fb05a2c..f0ab7f17

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

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

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

From serb at openjdk.java.net  Sat Sep  4 00:40:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 4 Sep 2021 00:40:54 GMT
Subject: <i18n dev> RFR: 8271603: Unnecessary Vector usage in
 java.desktop [v7]
In-Reply-To: <U-5c4xVAwDMZ9YOUFCwa0lbct7qJwxSVIY9lvdTvfhA=.d848f208-fa13-42d8-b823-38010d59ea19@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
 <U-5c4xVAwDMZ9YOUFCwa0lbct7qJwxSVIY9lvdTvfhA=.d848f208-fa13-42d8-b823-38010d59ea19@github.com>
Message-ID: <ZoOeT3iNtAwqgvhlnASSn0ubSr01rL31fH0vthVB-DM=.daf31df3-7ed2-4ba5-a2ac-1855c481a352@github.com>

On Fri, 3 Sep 2021 08:04:52 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
>> I checked only places where `Vector` was used as local variable.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271603: Unnecessary Vector usage in java.desktop
>   one more place to call toArray with zero-sized array

Marked as reviewed by serb (Reviewer).

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

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

From naoto at openjdk.java.net  Wed Sep  8 00:37:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 8 Sep 2021 00:37:41 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs [v2]
In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
Message-ID: <FV3J6cGi69EGljCkseklw51-qbZUThk3ufxjsb46xaI=.f560b14a-290d-46fd-9c49-17da1b0ba6db@github.com>

> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).

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

  Refined wordings.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5354/files
  - new: https://git.openjdk.java.net/jdk/pull/5354/files/294e3d72..dc36e741

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

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

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

From iris at openjdk.java.net  Wed Sep  8 01:10:10 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 8 Sep 2021 01:10:10 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs [v2]
In-Reply-To: <FV3J6cGi69EGljCkseklw51-qbZUThk3ufxjsb46xaI=.f560b14a-290d-46fd-9c49-17da1b0ba6db@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
 <FV3J6cGi69EGljCkseklw51-qbZUThk3ufxjsb46xaI=.f560b14a-290d-46fd-9c49-17da1b0ba6db@github.com>
Message-ID: <Fqmflhqr5dWwC_vIA_CCtC81D74t58hGx0jcVX93bsQ=.ab4290a9-2020-4191-87b4-583767683691@github.com>

On Wed, 8 Sep 2021 00:37:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined wordings.

Marked as reviewed by iris (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Sep  8 04:40:18 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 8 Sep 2021 04:40:18 GMT
Subject: <i18n dev> Integrated: 8271603: Unnecessary Vector usage in
 java.desktop
In-Reply-To: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
References: <hdHdAw2YkFb3bjjiY9aVTPYa92cFVn0reO2hlZR0vxw=.60aecb76-ae37-47d9-9650-486f5c513455@github.com>
Message-ID: <soATMn1pu-pRQjO4kz7YNsC6h5x9WfiWM3KwOxCI65k=.44de4811-3b00-4bc9-abc6-b75d66fad158@github.com>

On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checked only places where `Vector` was used as local variable.

This pull request has now been integrated.

Changeset: 1513dc7a
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1513dc7afc33386106439ccb9b7b16956b3c534a
Stats:     271 lines in 34 files changed: 19 ins; 31 del; 221 mod

8271603: Unnecessary Vector usage in java.desktop

Reviewed-by: prr, serb

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

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

From igraves at openjdk.java.net  Wed Sep  8 20:33:26 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 8 Sep 2021 20:33:26 GMT
Subject: <i18n dev> RFR: 8273430: Suspicious duplicate condition in
 java.util.regex.Grapheme#isExcludedSpacingMark
Message-ID: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>

The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks.

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

Commit messages:
 - 8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark

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

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

From naoto at openjdk.java.net  Wed Sep  8 20:46:07 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 8 Sep 2021 20:46:07 GMT
Subject: <i18n dev> RFR: 8273430: Suspicious duplicate condition in
 java.util.regex.Grapheme#isExcludedSpacingMark
In-Reply-To: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>
References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>
Message-ID: <ppPjfMAHcE4PuwgOMTq5LPbz30im7RT_TotzqDtdo-k=.07f55218-053f-4052-9fa7-904d65fd77b8@github.com>

On Wed, 8 Sep 2021 20:24:31 GMT, Ian Graves <igraves at openjdk.org> wrote:

> The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks.

The copyright year in Grapheme.java should be 2021, otherwise looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From wuyan at openjdk.java.net  Thu Sep  9 08:25:44 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Thu, 9 Sep 2021 08:25:44 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v2]
In-Reply-To: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
Message-ID: <X9ky2aTe5AzKj5vkv6bR4YPtkpNbI9wF-xAcpLy3xEw=.19fad7c2-a036-4b39-836a-73a447f27cf1@github.com>

> Hi,
> Please help me review the change to enhance getting  time zone ID from /etc/localtime on linux.
> 
> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname.
> 
> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?.
> 
> Thanks,
> wuyan

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

  replace realpath

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5327/files
  - new: https://git.openjdk.java.net/jdk/pull/5327/files/9b29edfc..19cc634d

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

  Stats: 395 lines in 4 files changed: 241 ins; 145 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5327.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5327/head:pull/5327

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

From wuyan at openjdk.java.net  Thu Sep  9 08:59:08 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Thu, 9 Sep 2021 08:59:08 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v2]
In-Reply-To: <X9ky2aTe5AzKj5vkv6bR4YPtkpNbI9wF-xAcpLy3xEw=.19fad7c2-a036-4b39-836a-73a447f27cf1@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <X9ky2aTe5AzKj5vkv6bR4YPtkpNbI9wF-xAcpLy3xEw=.19fad7c2-a036-4b39-836a-73a447f27cf1@github.com>
Message-ID: <L__02zgwOk1vrL9gN81K4r5KuYjRFYeNa6D1tevG7Kk=.3fe62d6d-139f-48c4-9ff2-b43c3f36422b@github.com>

On Thu, 9 Sep 2021 08:25:44 GMT, Wu Yan <wuyan at openjdk.org> wrote:

>> Hi,
>> Please help me review the change to enhance getting  time zone ID from /etc/localtime on linux.
>> 
>> We use `realpath` instead of `readlink` to obtain the link name of /etc/localtime, because `readlink` can only read the value of a symbolic of link, not the canonicalized absolute pathname.
>> 
>> For example, the value of /etc/localtime is "../usr/share/zoneinfo//Asia/Shanghai", then the linkbuf obtained by `readlink` is "../usr/share/zoneinfo//Asia/Shanghai", and then the call of `getZoneName(linkbuf)` will get "/Asia/Shanghai", not "Asia/Shanghai", which consider as invalid in `ZoneInfoFile.getZoneInfo()`. Using `realpath`, you can get ?/usr/share/zoneinfo/Asia/Shanghai? directly from ?/etc/localtime?.
>> 
>> Thanks,
>> wuyan
>
> Wu Yan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replace realpath

Hi, we directly process the characters in `linkbuf` instead of realpath. And we reuse [collapse()](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/canonicalize_md.c#L129) to process the '.' and '..' in `linkbuf`.

We tested some cases about /etc/localtime, and it works well. Test cases and results are in the attachment.
[testcase.log](https://github.com/openjdk/jdk/files/7135028/testcase.log)
[result.log](https://github.com/openjdk/jdk/files/7135030/result.log)

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

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

From naoto at openjdk.java.net  Fri Sep 10 12:21:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 10 Sep 2021 12:21:41 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs [v3]
In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
Message-ID: <LTwat4IEUaPU9xHMB3cwc0vLvORa3cVu1937AuZpUwE=.fdf1d150-ad6d-48de-8eb8-52412b6a288c@github.com>

> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).

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

 - Merge branch 'master' into JDK-8273259
 - Reflecting the CSR review comment
 - Refined wordings.
 - 8273259: Character.getName doesn't follow Unicode spec for ideographs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5354/files
  - new: https://git.openjdk.java.net/jdk/pull/5354/files/dc36e741..04034295

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

  Stats: 12617 lines in 569 files changed: 7866 ins; 2572 del; 2179 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5354/head:pull/5354

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

From iris at openjdk.java.net  Fri Sep 10 13:59:41 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 10 Sep 2021 13:59:41 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs [v3]
In-Reply-To: <LTwat4IEUaPU9xHMB3cwc0vLvORa3cVu1937AuZpUwE=.fdf1d150-ad6d-48de-8eb8-52412b6a288c@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
 <LTwat4IEUaPU9xHMB3cwc0vLvORa3cVu1937AuZpUwE=.fdf1d150-ad6d-48de-8eb8-52412b6a288c@github.com>
Message-ID: <C---VooNPMgNnGBDcbVKJO97TYFBoAwKU3p_71qZPm4=.f0c1f2ce-6e6f-4255-8780-82fb58e2db86@github.com>

On Fri, 10 Sep 2021 12:21:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8273259
>  - Reflecting the CSR review comment
>  - Refined wordings.
>  - 8273259: Character.getName doesn't follow Unicode spec for ideographs

Marked as reviewed by iris (Reviewer).

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

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

From joehw at openjdk.java.net  Fri Sep 10 18:14:49 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 10 Sep 2021 18:14:49 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict
In-Reply-To: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
Message-ID: <E7MhYrCzrtJ0QxOKF_GFvgqhFybvLxuGxzBGro8n1HY=.db082dff-1776-45b5-ab74-be3369ae4908@github.com>

On Thu, 9 Sep 2021 23:29:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Small spec clarification. Corresponding CSR has also been drafted.

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120:

> 118:  * the locale sensitive services separated by a comma. It is only read and cached at
> 119:  * the initialization of this class, so the later call to
> 120:  * {@link System#setProperty(String, String)} may not affect the order.

I wonder if we can be clearer as "may not" implies uncertainty. While it indeed may or may not work due to the timing of the initialization of this class, my understanding of the above statement is that it implied the runtime startup is recommended as it provides assurance. Would it be better to put that in the statement? sth. like: It is read once and cached at the Java runtime startup or initialization of this class. A call after the initialization of this class will not affect the order.

There's still uncertainty

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

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

From naoto at openjdk.java.net  Fri Sep 10 20:35:28 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 10 Sep 2021 20:35:28 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict [v2]
In-Reply-To: <E7MhYrCzrtJ0QxOKF_GFvgqhFybvLxuGxzBGro8n1HY=.db082dff-1776-45b5-ab74-be3369ae4908@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
 <E7MhYrCzrtJ0QxOKF_GFvgqhFybvLxuGxzBGro8n1HY=.db082dff-1776-45b5-ab74-be3369ae4908@github.com>
Message-ID: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com>

On Fri, 10 Sep 2021 18:11:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review comment.
>
> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120:
> 
>> 118:  * the locale sensitive services separated by a comma. It is only read and cached at
>> 119:  * the initialization of this class, so the later call to
>> 120:  * {@link System#setProperty(String, String)} may not affect the order.
> 
> I wonder if we can be clearer as "may not" implies uncertainty. While it indeed may or may not work due to the timing of the initialization of this class, my understanding of the above statement is that it implied the runtime startup is recommended as it provides assurance. Would it be better to put that in the statement? sth. like: It is read once and cached at the Java runtime startup or initialization of this class. A call after the initialization of this class will not affect the order.

It was intentional to use `may not` because as you said, there's still uncertainty. To clarify it more, I added wording that `setProperty` use is discouraged to change the preferred order.

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

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

From naoto at openjdk.java.net  Fri Sep 10 20:35:25 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 10 Sep 2021 20:35:25 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict [v2]
In-Reply-To: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
Message-ID: <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com>

> Small spec clarification. Corresponding CSR has also been drafted.

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

  Reflecting review comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5457/files
  - new: https://git.openjdk.java.net/jdk/pull/5457/files/2781ad32..70bfbd69

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

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

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

From joehw at openjdk.java.net  Fri Sep 10 20:56:49 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 10 Sep 2021 20:56:49 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict [v2]
In-Reply-To: <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
 <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com>
Message-ID: <_zEFOBYwH4HSehQO54L_63t3o-blOvn96BtELg77NCs=.696be05c-65fb-405d-b7ea-0fb7eb01642d@github.com>

On Fri, 10 Sep 2021 20:35:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Small spec clarification. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comment.

Marked as reviewed by joehw (Reviewer).

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

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

From joehw at openjdk.java.net  Fri Sep 10 20:56:50 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 10 Sep 2021 20:56:50 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict [v2]
In-Reply-To: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
 <E7MhYrCzrtJ0QxOKF_GFvgqhFybvLxuGxzBGro8n1HY=.db082dff-1776-45b5-ab74-be3369ae4908@github.com>
 <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com>
Message-ID: <HLfP4hJoA3lG0VZTPmYkEUVoeCONBLX--Tp4lUxf-IM=.d82cfee9-8dcf-4b4b-8853-e08a1f674ac0@github.com>

On Fri, 10 Sep 2021 20:32:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120:
>> 
>>> 118:  * the locale sensitive services separated by a comma. It is only read and cached at
>>> 119:  * the initialization of this class, so the later call to
>>> 120:  * {@link System#setProperty(String, String)} may not affect the order.
>> 
>> I wonder if we can be clearer as "may not" implies uncertainty. While it indeed may or may not work due to the timing of the initialization of this class, my understanding of the above statement is that it implied the runtime startup is recommended as it provides assurance. Would it be better to put that in the statement? sth. like: It is read once and cached at the Java runtime startup or initialization of this class. A call after the initialization of this class will not affect the order.
>
> It was intentional to use `may not` because as you said, there's still uncertainty. To clarify it more, I added wording that `setProperty` use is discouraged to change the preferred order.

That sounds good to me, suggesting doing it at launch while discouraging the use of setProperty.

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

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

From igraves at openjdk.java.net  Fri Sep 10 20:57:34 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 10 Sep 2021 20:57:34 GMT
Subject: <i18n dev> RFR: 8273430: Suspicious duplicate condition in
 java.util.regex.Grapheme#isExcludedSpacingMark [v2]
In-Reply-To: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>
References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>
Message-ID: <mZLrt2Wnyq60CgQGHuLzNV8042yeKwQVYns6EcT2YCQ=.5252b63c-a243-4c9c-9356-ecfbaaf42c0e@github.com>

> The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks.

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

  Refactoring test to whitebox

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5425/files
  - new: https://git.openjdk.java.net/jdk/pull/5425/files/ed2e4d2a..c60523af

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

  Stats: 545 lines in 4 files changed: 147 ins; 395 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5425/head:pull/5425

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

From igraves at openjdk.java.net  Fri Sep 10 21:02:45 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 10 Sep 2021 21:02:45 GMT
Subject: <i18n dev> RFR: 8273430: Suspicious duplicate condition in
 java.util.regex.Grapheme#isExcludedSpacingMark [v2]
In-Reply-To: <mZLrt2Wnyq60CgQGHuLzNV8042yeKwQVYns6EcT2YCQ=.5252b63c-a243-4c9c-9356-ecfbaaf42c0e@github.com>
References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>
 <mZLrt2Wnyq60CgQGHuLzNV8042yeKwQVYns6EcT2YCQ=.5252b63c-a243-4c9c-9356-ecfbaaf42c0e@github.com>
Message-ID: <bre8A12rQQNQDgTOr5ejoGB5LSXBAEdwiGS7K9edzss=.ff06253c-e7ae-4788-a34e-11ce42cbb818@github.com>

On Fri, 10 Sep 2021 20:57:34 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring test to whitebox

Updating the tests here. Existing ones included code copy/pasted directly from the unit under test. Refactored to a whitebox-style testing that injects accessors into `java.util.regex` so we don't have to modify code in two places to keep it in sync. Also relaxed two private static methods in `java.util.regex.Grapheme` to package-private so the injected accessor class can reach them and expose them for the test.

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

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

From naoto at openjdk.java.net  Fri Sep 10 21:12:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 10 Sep 2021 21:12:50 GMT
Subject: <i18n dev> RFR: 8273430: Suspicious duplicate condition in
 java.util.regex.Grapheme#isExcludedSpacingMark [v2]
In-Reply-To: <mZLrt2Wnyq60CgQGHuLzNV8042yeKwQVYns6EcT2YCQ=.5252b63c-a243-4c9c-9356-ecfbaaf42c0e@github.com>
References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>
 <mZLrt2Wnyq60CgQGHuLzNV8042yeKwQVYns6EcT2YCQ=.5252b63c-a243-4c9c-9356-ecfbaaf42c0e@github.com>
Message-ID: <1gQaiN6z_9DqZDBuBbdxmcfKrRwA0DWNQtICgq76qY0=.5e836544-30b5-4465-a08c-76c40a8ef556@github.com>

On Fri, 10 Sep 2021 20:57:34 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring test to whitebox

Looks good. Nice cleanup!

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

Marked as reviewed by naoto (Reviewer).

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

From prappo at openjdk.java.net  Fri Sep 10 21:25:00 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 10 Sep 2021 21:25:00 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module
Message-ID: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>

8273616: Fix trivial doc typos in the java.base module

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

Commit messages:
 - Initial commit

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

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

From jrose at openjdk.java.net  Fri Sep 10 21:58:48 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Fri, 10 Sep 2021 21:58:48 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module
In-Reply-To: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
Message-ID: <h2qSCxuOU4uKmp6015YOorPnzGIQrTXTpmpskGpcQhU=.4fb0a8f5-79a0-48c8-a217-0375ca948082@github.com>

On Fri, 10 Sep 2021 21:16:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 8273616: Fix trivial doc typos in the java.base module

Approved, except for two changes commented above: the original "it need only force" is correct usage, and "it needs only force" is not good usage, but "it only needs to force" would be clearer and also correct.

src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java line 399:

> 397:      *          If {@code true} then this method is required to force changes
> 398:      *          to both the file's content and metadata to be written to
> 399:      *          storage; otherwise, it needs only force content changes to be

This is a correct though rare use of subjunctive mood:  One need not change it.
However, if be desired that we change the mood to indicative, I suggest s/it need only force/it only needs to force/.

src/java.base/share/classes/java/nio/channels/FileChannel.java line 567:

> 565:      *          If {@code true} then this method is required to force changes
> 566:      *          to both the file's content and metadata to be written to
> 567:      *          storage; otherwise, it needs only force content changes to be

(same as previous comment:  the suggested fix makes the English *less* correct)

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

Marked as reviewed by jrose (Reviewer).

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

From github.com+592810+efge at openjdk.java.net  Fri Sep 10 22:55:43 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Fri, 10 Sep 2021 22:55:43 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module
In-Reply-To: <h2qSCxuOU4uKmp6015YOorPnzGIQrTXTpmpskGpcQhU=.4fb0a8f5-79a0-48c8-a217-0375ca948082@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <h2qSCxuOU4uKmp6015YOorPnzGIQrTXTpmpskGpcQhU=.4fb0a8f5-79a0-48c8-a217-0375ca948082@github.com>
Message-ID: <I2m-THLURWyO01pdJV6PmIetWHvGarxHkIcMbskICyc=.91f1069b-29dc-4c6a-a154-1e47e751de5d@github.com>

On Fri, 10 Sep 2021 21:51:45 GMT, John R Rose <jrose at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java line 399:
> 
>> 397:      *          If {@code true} then this method is required to force changes
>> 398:      *          to both the file's content and metadata to be written to
>> 399:      *          storage; otherwise, it needs only force content changes to be
> 
> This is a correct though rare use of subjunctive mood:  One need not change it.
> However, if be desired that we change the mood to indicative, I suggest s/it need only force/it only needs to force/.

(_it need only force_ is not really subjunctive mood, but rather usage as a modal auxiliary, see https://english.stackexchange.com/a/297235)

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

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

From darcy at openjdk.java.net  Fri Sep 10 23:14:59 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 10 Sep 2021 23:14:59 GMT
Subject: <i18n dev> RFR: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs [v3]
In-Reply-To: <LTwat4IEUaPU9xHMB3cwc0vLvORa3cVu1937AuZpUwE=.fdf1d150-ad6d-48de-8eb8-52412b6a288c@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
 <LTwat4IEUaPU9xHMB3cwc0vLvORa3cVu1937AuZpUwE=.fdf1d150-ad6d-48de-8eb8-52412b6a288c@github.com>
Message-ID: <8IAkYctKoeaTyFcsgmLEe0-zOecIYMZeU5hP7LILbqo=.a9e297ce-013e-4fd5-affb-02297b192f53@github.com>

On Fri, 10 Sep 2021 12:21:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8273259
>  - Reflecting the CSR review comment
>  - Refined wordings.
>  - 8273259: Character.getName doesn't follow Unicode spec for ideographs

Marked as reviewed by darcy (Reviewer).

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

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

From prappo at openjdk.java.net  Fri Sep 10 23:20:12 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 10 Sep 2021 23:20:12 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v2]
In-Reply-To: <h2qSCxuOU4uKmp6015YOorPnzGIQrTXTpmpskGpcQhU=.4fb0a8f5-79a0-48c8-a217-0375ca948082@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <h2qSCxuOU4uKmp6015YOorPnzGIQrTXTpmpskGpcQhU=.4fb0a8f5-79a0-48c8-a217-0375ca948082@github.com>
Message-ID: <AEJSIGbv1m79dK5HZN-tLPjDjwBgRN_XpbE2x5z-UVE=.ddeb9abf-d365-4304-9f38-f7bf90e7a7f7@github.com>

On Fri, 10 Sep 2021 21:52:36 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert two fixes
>
> src/java.base/share/classes/java/nio/channels/FileChannel.java line 567:
> 
>> 565:      *          If {@code true} then this method is required to force changes
>> 566:      *          to both the file's content and metadata to be written to
>> 567:      *          storage; otherwise, it needs only force content changes to be
> 
> (same as previous comment:  the suggested fix makes the English *less* correct)

Reverted both in 9a9deee; thanks.

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

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

From prappo at openjdk.java.net  Fri Sep 10 23:20:11 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 10 Sep 2021 23:20:11 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v2]
In-Reply-To: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
Message-ID: <prCGEqwbwLtjFYznjsO2pgn32XvJ-ST6BgZNqT--tWE=.cdd11c8a-0e0e-4ff4-a4ee-cfd688b1de22@github.com>

> 8273616: Fix trivial doc typos in the java.base module

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

  Revert two fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5475/files
  - new: https://git.openjdk.java.net/jdk/pull/5475/files/b90d1556..9a9deee1

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

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

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

From iris at openjdk.java.net  Sat Sep 11 00:55:44 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Sat, 11 Sep 2021 00:55:44 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v2]
In-Reply-To: <prCGEqwbwLtjFYznjsO2pgn32XvJ-ST6BgZNqT--tWE=.cdd11c8a-0e0e-4ff4-a4ee-cfd688b1de22@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <prCGEqwbwLtjFYznjsO2pgn32XvJ-ST6BgZNqT--tWE=.cdd11c8a-0e0e-4ff4-a4ee-cfd688b1de22@github.com>
Message-ID: <yB8qyBzaGHaa2LPLq0RLFe9b3ZF2wAvDCXOj8dFZ2-U=.b33eb8f6-13ce-48c1-a1f2-fc3f38ac5615@github.com>

On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert two fixes

Marked as reviewed by iris (Reviewer).

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

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

From lancea at openjdk.java.net  Sat Sep 11 11:09:48 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 11 Sep 2021 11:09:48 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict [v2]
In-Reply-To: <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
 <E7MhYrCzrtJ0QxOKF_GFvgqhFybvLxuGxzBGro8n1HY=.db082dff-1776-45b5-ab74-be3369ae4908@github.com>
 <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com>
Message-ID: <K8zLE1N-Qk7dQ94KewaiP_1yI-0zAfGHUjsTXzLhJL4=.0bbdc84a-ab49-4c9e-9ce0-bf18a3fcad79@github.com>

On Fri, 10 Sep 2021 20:32:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120:
>> 
>>> 118:  * the locale sensitive services separated by a comma. It is only read and cached at
>>> 119:  * the initialization of this class, so the later call to
>>> 120:  * {@link System#setProperty(String, String)} may not affect the order.
>> 
>> I wonder if we can be clearer as "may not" implies uncertainty. While it indeed may or may not work due to the timing of the initialization of this class, my understanding of the above statement is that it implied the runtime startup is recommended as it provides assurance. Would it be better to put that in the statement? sth. like: It is read once and cached at the Java runtime startup or initialization of this class. A call after the initialization of this class will not affect the order.
>
> It was intentional to use `may not` because as you said, there's still uncertainty. To clarify it more, I added wording that `setProperty` use is discouraged to change the preferred order.

Hi Naoto,

A couple of questions:

- Are there any scenarios where invoking setProperty will not override the command line setting ?
- Did you consider an `@ImplNote` for your clarification given the behavior "might" be different in other implementations (I am not sure myself) and is implementation defined?

Best
Lance

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

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

From naoto at openjdk.java.net  Sat Sep 11 14:02:46 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sat, 11 Sep 2021 14:02:46 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict [v2]
In-Reply-To: <HLfP4hJoA3lG0VZTPmYkEUVoeCONBLX--Tp4lUxf-IM=.d82cfee9-8dcf-4b4b-8853-e08a1f674ac0@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
 <E7MhYrCzrtJ0QxOKF_GFvgqhFybvLxuGxzBGro8n1HY=.db082dff-1776-45b5-ab74-be3369ae4908@github.com>
 <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com>
 <HLfP4hJoA3lG0VZTPmYkEUVoeCONBLX--Tp4lUxf-IM=.d82cfee9-8dcf-4b4b-8853-e08a1f674ac0@github.com>
Message-ID: <3ZahQVUuID0T_d1E25ER9yfhFUHtA5Lcb9V3TwW5Dkg=.06e1a3a6-7398-4f06-8886-bd03040503d2@github.com>

On Fri, 10 Sep 2021 20:53:35 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Hi Naoto,
>> 
>> A couple of questions:
>> 
>> - Are there any scenarios where invoking setProperty will not override the command line setting ?
>> - Did you consider an `@ImplNote` for your clarification given the behavior "might" be different in other implementations (I am not sure myself) and is implementation defined?
>> 
>> Best
>> Lance
>
> That sounds good to me, suggesting doing it at launch while discouraging the use of setProperty.

Hi Lance,

> * Are there any scenarios where invoking setProperty will not override the command line setting ?

Yes. For example, if a logger is installed, it formats the log date/time which causes initialization of locale-related classes before the app's main() method invocation, resulting setProperty() having no effect.

> * Did you consider an `@ImplNote` for your clarification given the behavior "might" be different in other implementations (I am not sure myself) and is implementation defined?

As in the above example, the behavior changes regardless of the implementation of the runtime. The clarification is mainly for the API consumer, rather than platform implementors.

Hope this answers your questions.

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

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

From lancea at openjdk.java.net  Sat Sep 11 15:02:52 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 11 Sep 2021 15:02:52 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict [v2]
In-Reply-To: <3ZahQVUuID0T_d1E25ER9yfhFUHtA5Lcb9V3TwW5Dkg=.06e1a3a6-7398-4f06-8886-bd03040503d2@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
 <E7MhYrCzrtJ0QxOKF_GFvgqhFybvLxuGxzBGro8n1HY=.db082dff-1776-45b5-ab74-be3369ae4908@github.com>
 <6QAY-otAZ7nOSgzBbA7WP8KPxeAgykHdBJVwcHz2NL8=.927a7fee-a360-4322-9bf5-2b1e67421773@github.com>
 <HLfP4hJoA3lG0VZTPmYkEUVoeCONBLX--Tp4lUxf-IM=.d82cfee9-8dcf-4b4b-8853-e08a1f674ac0@github.com>
 <3ZahQVUuID0T_d1E25ER9yfhFUHtA5Lcb9V3TwW5Dkg=.06e1a3a6-7398-4f06-8886-bd03040503d2@github.com>
Message-ID: <gt8dNKTlKr2swUZr6T6x_5GT6Qt_1tVb7zdxu0KeUPE=.8ced72a9-4b0d-4c98-9ea1-5c899a04949b@github.com>

On Sat, 11 Sep 2021 13:59:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> That sounds good to me, suggesting doing it at launch while discouraging the use of setProperty.
>
> Hi Lance,
> 
>> * Are there any scenarios where invoking setProperty will not override the command line setting ?
> 
> Yes. For example, if a logger is installed, it formats the log date/time which causes initialization of locale-related classes before the app's main() method invocation, resulting setProperty() having no effect.
> 
>> * Did you consider an `@ImplNote` for your clarification given the behavior "might" be different in other implementations (I am not sure myself) and is implementation defined?
> 
> As in the above example, the behavior changes regardless of the implementation of the runtime. The clarification is mainly for the API consumer, rather than platform implementors.
> 
> Hope this answers your questions.

Hi Naoto,

Thank you for the clarification.  Yes it makes sense.

Best
Lance

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

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

From lancea at openjdk.java.net  Sat Sep 11 15:02:52 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 11 Sep 2021 15:02:52 GMT
Subject: <i18n dev> RFR: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict [v2]
In-Reply-To: <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
 <9vqR_Aqw-VATdBcDldc00t5J7pLtq9NXFVk8DfJ8eFM=.3de32058-5443-4556-b819-e09b188b0de2@github.com>
Message-ID: <Mt2deqx4DaW0Ygnc_Q-yaMzBcJuz0KaY7ffDmnRzSKE=.7f651789-a096-4b6d-bda4-e788e0b8a062@github.com>

On Fri, 10 Sep 2021 20:35:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Small spec clarification. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comment.

Marked as reviewed by lancea (Reviewer).

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

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

From lancea at openjdk.java.net  Sat Sep 11 15:05:49 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sat, 11 Sep 2021 15:05:49 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v2]
In-Reply-To: <prCGEqwbwLtjFYznjsO2pgn32XvJ-ST6BgZNqT--tWE=.cdd11c8a-0e0e-4ff4-a4ee-cfd688b1de22@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <prCGEqwbwLtjFYznjsO2pgn32XvJ-ST6BgZNqT--tWE=.cdd11c8a-0e0e-4ff4-a4ee-cfd688b1de22@github.com>
Message-ID: <siVSCc6RzX0QupmBFM95UuS6hFzqNoETyH8kEIjPbAo=.a56e8d43-2f87-4cdc-ad71-3343846ca863@github.com>

On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert two fixes

Marked as reviewed by lancea (Reviewer).

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

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

From prappo at openjdk.java.net  Mon Sep 13 11:22:27 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 13 Sep 2021 11:22:27 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v3]
In-Reply-To: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
Message-ID: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>

> 8273616: Fix trivial doc typos in the java.base module

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

  Use "ensure" instead of "insure"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5475/files
  - new: https://git.openjdk.java.net/jdk/pull/5475/files/9a9deee1..4b33fb94

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

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

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

From prappo at openjdk.java.net  Mon Sep 13 11:22:30 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 13 Sep 2021 11:22:30 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v2]
In-Reply-To: <prCGEqwbwLtjFYznjsO2pgn32XvJ-ST6BgZNqT--tWE=.cdd11c8a-0e0e-4ff4-a4ee-cfd688b1de22@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <prCGEqwbwLtjFYznjsO2pgn32XvJ-ST6BgZNqT--tWE=.cdd11c8a-0e0e-4ff4-a4ee-cfd688b1de22@github.com>
Message-ID: <N7OenTYjef6-Sd9zxJ0KXe5Zlh2esgUIi9B33aODZPM=.e99d2863-dd88-4f85-8814-51a1d4bb2433@github.com>

On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert two fixes

Thanks to those who reviewed this PR. Since I posted it, I've found three more occurrences of _insure_ used in the sense of _ensure_: two in the `java.io.Object*Stream` area and one in the `java.util.Currency` class. I decided to fix those in this PR, which now needs to be (re)reviewed. Thanks!

There are more occurrences of _insure_, which I didn't touch. Some of them are in java.sql, java.sql.rowset and java.desktop. In the latter, _insure_ even crept into method names.

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

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

From dfuchs at openjdk.java.net  Mon Sep 13 13:11:57 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 13 Sep 2021 13:11:57 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v3]
In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
Message-ID: <FIoykA8ISte-SEY9RGkkQxqrHz2SKu9rbolkqByp9ts=.d9c15fda-da21-4a3c-9c2d-0ff19e697993@github.com>

On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "ensure" instead of "insure"

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

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

From rriggs at openjdk.java.net  Mon Sep 13 13:34:08 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 13 Sep 2021 13:34:08 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v3]
In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
Message-ID: <MXANkQt2a0BuSWzqzA921FPRqqBB9UIuEl-Ck1HgLB0=.f007f710-ed63-407c-99fc-eedb3e3c9a39@github.com>

On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "ensure" instead of "insure"

Marked as reviewed by rriggs (Reviewer).

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

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

From iris at openjdk.java.net  Mon Sep 13 15:16:54 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 13 Sep 2021 15:16:54 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v3]
In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
Message-ID: <I98Bp5tDGjm7NgaCnh_3QnU1sRP4ewqlCFu0llJN2K0=.88e5349c-dbea-46f4-90e6-13d111dac822@github.com>

On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "ensure" instead of "insure"

Marked as reviewed by iris (Reviewer).

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

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

From naoto at openjdk.java.net  Mon Sep 13 16:10:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 13 Sep 2021 16:10:03 GMT
Subject: <i18n dev> Integrated: 8273259: Character.getName doesn't follow
 Unicode spec for ideographs
In-Reply-To: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
References: <3ZOCioU8lMEPuWdaYlBv8L6oNdIwVjwZpPbKLWwkOjs=.0e8939c8-9cff-4600-a869-9c5f137fd2e5@github.com>
Message-ID: <ita22rmx1Euz1UlbvS_wqLBzYvWeW05GF02ZVOITFfg=.26e1fb66-ad5f-4707-9c22-f602da14c3d2@github.com>

On Thu, 2 Sep 2021 19:26:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple spec clarification. A CSR has also been drafted (https://bugs.openjdk.java.net/browse/JDK-8273296).

This pull request has now been integrated.

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

8273259: Character.getName doesn't follow Unicode spec for ideographs

Reviewed-by: bpb, lancea, iris, darcy

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

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

From lancea at openjdk.java.net  Mon Sep 13 16:23:58 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 13 Sep 2021 16:23:58 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v3]
In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
Message-ID: <7B5F0eR1t3Y3RrxNeDG8VxLJpO4JVD-cXFBY5YbEErw=.8f5679bf-98cf-4670-97bb-b58c64ce1147@github.com>

On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "ensure" instead of "insure"

Marked as reviewed by lancea (Reviewer).

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

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

From jrose at openjdk.java.net  Mon Sep 13 17:19:55 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 13 Sep 2021 17:19:55 GMT
Subject: <i18n dev> RFR: 8273616: Fix trivial doc typos in the java.base
 module [v3]
In-Reply-To: <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
 <-FYpghxAFYk15OireziuPEkSxKJUSndwl70Ti2HDUUk=.3062ce6e-2d19-48ff-91c8-02640ca6f39a@github.com>
Message-ID: <MUCifYvkH7RkUYgOgYkZCeZDmtqghLSdgqCpmV0sxHc=.947c7319-3762-4560-aecb-32de6c6552ab@github.com>

On Mon, 13 Sep 2021 11:22:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 8273616: Fix trivial doc typos in the java.base module
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use "ensure" instead of "insure"

Marked as reviewed by jrose (Reviewer).

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

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

From prappo at openjdk.java.net  Mon Sep 13 17:48:58 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 13 Sep 2021 17:48:58 GMT
Subject: <i18n dev> Integrated: 8273616: Fix trivial doc typos in the
 java.base module
In-Reply-To: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
References: <ZHUxFU_KLBSyysSwaVhHDS7ihQ1lebURrj3kv8FARMI=.d1884858-9524-4087-8eaf-7ffa1bd863cd@github.com>
Message-ID: <pjEcPcSruqayA7iCcX_qSDcd3d21kcpshyngdVRbx80=.14d8404e-ce48-4f0b-a151-8431ffbe75e0@github.com>

On Fri, 10 Sep 2021 21:16:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 8273616: Fix trivial doc typos in the java.base module

This pull request has now been integrated.

Changeset: b4b12101
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b4b121018d16e531f3a51ff75ae37fdc374d530b
Stats:     55 lines in 34 files changed: 0 ins; 0 del; 55 mod

8273616: Fix trivial doc typos in the java.base module

Reviewed-by: jrose, iris, lancea, dfuchs, rriggs

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

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

From igraves at openjdk.java.net  Mon Sep 13 21:54:11 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 13 Sep 2021 21:54:11 GMT
Subject: <i18n dev> Integrated: 8273430: Suspicious duplicate condition in
 java.util.regex.Grapheme#isExcludedSpacingMark
In-Reply-To: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>
References: <7eQexh7uLUwH-Mh_P_Hdq4clffXUKIRsHhVBWEUYNuA=.04a7b8fa-ba90-4a01-9c08-99604a76c7c2@github.com>
Message-ID: <BIHX5TUPPDFiwaJ6KUJ2w_lh2eNmg_QnaXaBsjRK4x8=.10150e6e-f4aa-4e77-93d1-6ea9b96e2cfd@github.com>

On Wed, 8 Sep 2021 20:24:31 GMT, Ian Graves <igraves at openjdk.org> wrote:

> The duplicate condition in this chain of expressions needs to be shrunk to drop a couple of character that are not excluded spacing marks.

This pull request has now been integrated.

Changeset: 3d9dc8f8
Author:    Ian Graves <igraves at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d9dc8f824abf597d9b28f456cfeb5af927221b8
Stats:     539 lines in 4 files changed: 147 ins; 388 del; 4 mod

8273430: Suspicious duplicate condition in java.util.regex.Grapheme#isExcludedSpacingMark

Reviewed-by: naoto

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

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

From naoto at openjdk.java.net  Tue Sep 14 12:49:12 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 14 Sep 2021 12:49:12 GMT
Subject: <i18n dev> Integrated: 8273491: java.util.spi.LocaleServiceProvider
 spec contains statement that is too strict
In-Reply-To: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
References: <egflssHkzjZcXN-cg9jGnAp_3z2_ee5PfuR5pcOkLKw=.9d40ea04-8740-45bb-a6b8-772170731aa8@github.com>
Message-ID: <rGXlo6sx7ZCW8SH57ZE61tV4KduXSLGa6RK8G9QOR_4=.8e16d028-281f-47db-ab0b-75a1cdf135a9@github.com>

On Thu, 9 Sep 2021 23:29:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Small spec clarification. Corresponding CSR has also been drafted.

This pull request has now been integrated.

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

8273491: java.util.spi.LocaleServiceProvider spec contains statement that is too strict

Reviewed-by: joehw, lancea

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Sep 20 11:58:53 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 20 Sep 2021 11:58:53 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop
In-Reply-To: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
Message-ID: <LSqf1R0_ikoaW6UNtFVzuZQcEkjaVsuz35QzPNTVMIc=.394b7c0a-c381-4b75-a85e-ed09cfda7044@github.com>

On Fri, 20 Aug 2021 09:41:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a continuation of
> 
> - https://bugs.openjdk.java.net/browse/JDK-6736490
> - https://bugs.openjdk.java.net/browse/JDK-8035284
> - https://bugs.openjdk.java.net/browse/JDK-8145680
> - https://bugs.openjdk.java.net/browse/JDK-8251548
> 
> As mentioned in JDK-6736490:
> 
> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._

As I can see there are a few more zero-initializations of volatiles. Are they intentionally skipped?
1. sun.lwawt.macosx.CPlatformEmbeddedFrame#screenX
2. sun.lwawt.macosx.CPlatformEmbeddedFrame#screenY
3. sun.lwawt.macosx.CWarningWindow#currentIcon
4. com.sun.media.sound.SoftSynthesizer.WeakAudioStream#silent_samples

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue Sep 21 11:37:42 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: Tue, 21 Sep 2021 11:37:42 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v2]
In-Reply-To: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
Message-ID: <csenEuZ1tDdW2ikoycJqLBg7s4XAYKYPVl56wtmE6Sk=.68d6bdd5-adcd-473f-b086-a3b9e202df9b@github.com>

> This is a continuation of
> 
> - https://bugs.openjdk.java.net/browse/JDK-6736490
> - https://bugs.openjdk.java.net/browse/JDK-8035284
> - https://bugs.openjdk.java.net/browse/JDK-8145680
> - https://bugs.openjdk.java.net/browse/JDK-8251548
> 
> As mentioned in JDK-6736490:
> 
> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._

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

  8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5197/files
  - new: https://git.openjdk.java.net/jdk/pull/5197/files/d06aff5b..a3558d0a

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Tue Sep 21 11:44:49 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: Tue, 21 Sep 2021 11:44:49 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop
In-Reply-To: <LSqf1R0_ikoaW6UNtFVzuZQcEkjaVsuz35QzPNTVMIc=.394b7c0a-c381-4b75-a85e-ed09cfda7044@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <LSqf1R0_ikoaW6UNtFVzuZQcEkjaVsuz35QzPNTVMIc=.394b7c0a-c381-4b75-a85e-ed09cfda7044@github.com>
Message-ID: <hXYYNMkrGNw0iu4zOR5wd1nO-iAbd2vcxB5oAtLpF2Y=.83091259-71e5-4721-8e9f-6e4e52105eee@github.com>

On Mon, 20 Sep 2021 11:55:43 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This is a continuation of
>> 
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK-8251548
>> 
>> As mentioned in JDK-6736490:
>> 
>> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._
>
> As I can see there are a few more zero-initializations of volatiles. Are they intentionally skipped?
> 1. sun.lwawt.macosx.CPlatformEmbeddedFrame#screenX
> 2. sun.lwawt.macosx.CPlatformEmbeddedFrame#screenY
> 3. sun.lwawt.macosx.CWarningWindow#currentIcon
> 4. com.sun.media.sound.SoftSynthesizer.WeakAudioStream#silent_samples

@turbanoff nice catch! I've missed them in my original commit, no intention here. I've included them either.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Sep 21 11:52:57 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 21 Sep 2021 11:52:57 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v2]
In-Reply-To: <csenEuZ1tDdW2ikoycJqLBg7s4XAYKYPVl56wtmE6Sk=.68d6bdd5-adcd-473f-b086-a3b9e202df9b@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <csenEuZ1tDdW2ikoycJqLBg7s4XAYKYPVl56wtmE6Sk=.68d6bdd5-adcd-473f-b086-a3b9e202df9b@github.com>
Message-ID: <InTvtP4Xvp4zfn7wdTts49EBZFsBiprwAM5GwiQPkr4=.8953184f-6520-43f0-8333-29d39813a54b@github.com>

On Tue, 21 Sep 2021 11:37:42 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> This is a continuation of
>> 
>> - https://bugs.openjdk.java.net/browse/JDK-6736490
>> - https://bugs.openjdk.java.net/browse/JDK-8035284
>> - https://bugs.openjdk.java.net/browse/JDK-8145680
>> - https://bugs.openjdk.java.net/browse/JDK-8251548
>> 
>> As mentioned in JDK-6736490:
>> 
>> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

Marked as reviewed by turbanoff at github.com (no known OpenJDK username).

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

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

From naoto at openjdk.java.net  Tue Sep 21 12:56:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 21 Sep 2021 12:56:06 GMT
Subject: <i18n dev> RFR: 8273924: ArrayIndexOutOfBoundsException thrown in
 java.util.JapaneseImperialCalendar.add()
Message-ID: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>

Fixing an AIOOBE on normalizing the month value.

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

Commit messages:
 - 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

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

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

From rriggs at openjdk.java.net  Tue Sep 21 13:23:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 21 Sep 2021 13:23:53 GMT
Subject: <i18n dev> RFR: 8273924: ArrayIndexOutOfBoundsException thrown
 in java.util.JapaneseImperialCalendar.add()
In-Reply-To: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
References: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
Message-ID: <zT9BMvP-2OtUgPxXVJ8XtiIrmvOCJiOwzOH1x7aL3BA=.cd0c96da-3edd-40d2-9924-20bef4c57a96@github.com>

On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an AIOOBE on normalizing the month value.

Marked as reviewed by rriggs (Reviewer).

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

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

From iris at openjdk.java.net  Tue Sep 21 16:51:35 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 21 Sep 2021 16:51:35 GMT
Subject: <i18n dev> RFR: 8273924: ArrayIndexOutOfBoundsException thrown
 in java.util.JapaneseImperialCalendar.add()
In-Reply-To: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
References: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
Message-ID: <H3oT0KABpwiJSBwGyB_3vBLLCdJyzt7OIDmKFhohZlw=.42300a3e-5963-425c-89d4-8ffabc6cb5de@github.com>

On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an AIOOBE on normalizing the month value.

Marked as reviewed by iris (Reviewer).

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

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

From naoto at openjdk.java.net  Tue Sep 21 21:56:28 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 21 Sep 2021 21:56:28 GMT
Subject: <i18n dev> RFR: 8273546: DecimalFormat documentation contains
 literal HTML character references
Message-ID: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>

Simple doc fix.

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

Commit messages:
 - 8273546: DecimalFormat documentation contains literal HTML character references

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

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

From joehw at openjdk.java.net  Tue Sep 21 22:09:00 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 21 Sep 2021 22:09:00 GMT
Subject: <i18n dev> RFR: 8273924: ArrayIndexOutOfBoundsException thrown
 in java.util.JapaneseImperialCalendar.add()
In-Reply-To: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
References: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
Message-ID: <4XI5Sru_mY9hTsoVdcwOHFsGuhwGHpu5JjMrLhQDhgg=.d28210f6-22fd-4844-b663-3ef486535078@github.com>

On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an AIOOBE on normalizing the month value.

Marked as reviewed by joehw (Reviewer).

src/java.base/share/classes/sun/util/calendar/BaseCalendar.java line 281:

> 279:             month = 13 - (xm % 12);
> 280:             if (month == 13) {
> 281:                 year ++;

Not that it matters, just happen to see it ;-). Is it more common to have no space before the increment operator? Code convention seems to suggest no space before increment and their operands. 
No update needed should you decide to remove it.

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

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

From naoto at openjdk.java.net  Tue Sep 21 22:18:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 21 Sep 2021 22:18:08 GMT
Subject: <i18n dev> RFR: 8273924: ArrayIndexOutOfBoundsException thrown
 in java.util.JapaneseImperialCalendar.add() [v2]
In-Reply-To: <4XI5Sru_mY9hTsoVdcwOHFsGuhwGHpu5JjMrLhQDhgg=.d28210f6-22fd-4844-b663-3ef486535078@github.com>
References: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
 <4XI5Sru_mY9hTsoVdcwOHFsGuhwGHpu5JjMrLhQDhgg=.d28210f6-22fd-4844-b663-3ef486535078@github.com>
Message-ID: <fuWlHodqDupSpfg-J8e9e10-t1qT8Q7hWb_r4pvMzYg=.9ea7bc91-20f7-4370-8d6d-597f34171261@github.com>

On Tue, 21 Sep 2021 22:03:30 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed the unnecessary space
>
> src/java.base/share/classes/sun/util/calendar/BaseCalendar.java line 281:
> 
>> 279:             month = 13 - (xm % 12);
>> 280:             if (month == 13) {
>> 281:                 year ++;
> 
> Not that it matters, just happen to see it ;-). Is it more common to have no space before the increment operator? Code convention seems to suggest no space before increment and their operands. 
> No update needed should you decide to remove it.

Thanks. Indeed it was in the coding convention. Removed.

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

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

From naoto at openjdk.java.net  Tue Sep 21 22:18:07 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 21 Sep 2021 22:18:07 GMT
Subject: <i18n dev> RFR: 8273924: ArrayIndexOutOfBoundsException thrown
 in java.util.JapaneseImperialCalendar.add() [v2]
In-Reply-To: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
References: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
Message-ID: <t8EM8dmSPcGW_t2z-ZauytIoIOduRsIgRy0GUH2pf0o=.d36630dc-60b9-4804-9494-c5a0204a6ef6@github.com>

> Fixing an AIOOBE on normalizing the month value.

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

  Removed the unnecessary space

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5611/files
  - new: https://git.openjdk.java.net/jdk/pull/5611/files/92f81963..98612bf5

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

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

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

From joehw at openjdk.java.net  Tue Sep 21 22:23:00 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 21 Sep 2021 22:23:00 GMT
Subject: <i18n dev> RFR: 8273924: ArrayIndexOutOfBoundsException thrown
 in java.util.JapaneseImperialCalendar.add() [v2]
In-Reply-To: <t8EM8dmSPcGW_t2z-ZauytIoIOduRsIgRy0GUH2pf0o=.d36630dc-60b9-4804-9494-c5a0204a6ef6@github.com>
References: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
 <t8EM8dmSPcGW_t2z-ZauytIoIOduRsIgRy0GUH2pf0o=.d36630dc-60b9-4804-9494-c5a0204a6ef6@github.com>
Message-ID: <xAbEfNjP_P6cJcDIIKG_lM_Rvtnt4ZHjHSdj2pxlWN0=.39742476-3e29-483e-bfdf-845c1ff9655b@github.com>

On Tue, 21 Sep 2021 22:18:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an AIOOBE on normalizing the month value.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the unnecessary space

Marked as reviewed by joehw (Reviewer).

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

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

From joehw at openjdk.java.net  Tue Sep 21 22:24:10 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 21 Sep 2021 22:24:10 GMT
Subject: <i18n dev> RFR: 8273546: DecimalFormat documentation contains
 literal HTML character references
In-Reply-To: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
References: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
Message-ID: <DSGSkGj1CxSA5MHkDcOq7G1fYX8_nf5YwSC9AwBWp5o=.d1f8ec1b-575c-44c2-936f-acc7e61e82e0@github.com>

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

Marked as reviewed by joehw (Reviewer).

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

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

From bpb at openjdk.java.net  Tue Sep 21 22:34:55 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 21 Sep 2021 22:34:55 GMT
Subject: <i18n dev> RFR: 8273546: DecimalFormat documentation contains
 literal HTML character references
In-Reply-To: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
References: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
Message-ID: <PrRwbQ-Z8oCVq5Z7bdaH5JdKy7sMlbHmHpttBcD8bvU=.6e84168b-8b0c-4cda-8ccb-cb1607334fc9@github.com>

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

Marked as reviewed by bpb (Reviewer).

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

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

From iris at openjdk.java.net  Tue Sep 21 22:49:00 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 21 Sep 2021 22:49:00 GMT
Subject: <i18n dev> RFR: 8273546: DecimalFormat documentation contains
 literal HTML character references
In-Reply-To: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
References: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
Message-ID: <zEmZICMX7beQgO9Z85HvNr5bU8sRpagYXraTF12zHYE=.72cd7d64-9ef1-4896-bcc3-a4bf0ac30d44@github.com>

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

Marked as reviewed by iris (Reviewer).

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

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

From iris at openjdk.java.net  Tue Sep 21 22:49:59 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 21 Sep 2021 22:49:59 GMT
Subject: <i18n dev> RFR: 8273924: ArrayIndexOutOfBoundsException thrown
 in java.util.JapaneseImperialCalendar.add() [v2]
In-Reply-To: <t8EM8dmSPcGW_t2z-ZauytIoIOduRsIgRy0GUH2pf0o=.d36630dc-60b9-4804-9494-c5a0204a6ef6@github.com>
References: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
 <t8EM8dmSPcGW_t2z-ZauytIoIOduRsIgRy0GUH2pf0o=.d36630dc-60b9-4804-9494-c5a0204a6ef6@github.com>
Message-ID: <KMvCF6uDbOc-3sMQmTU6SyYjQ4aTC_sVXzkUYgBHbcw=.b1174c18-a499-48d3-9a15-8b2b3713d449@github.com>

On Tue, 21 Sep 2021 22:18:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing an AIOOBE on normalizing the month value.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the unnecessary space

Marked as reviewed by iris (Reviewer).

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

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

From lancea at openjdk.java.net  Tue Sep 21 23:11:57 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 21 Sep 2021 23:11:57 GMT
Subject: <i18n dev> RFR: 8273546: DecimalFormat documentation contains
 literal HTML character references
In-Reply-To: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
References: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
Message-ID: <FjQvMZiHtaX_2OOZk5TSFLC2hzOB786LnK4N7Rt082s=.7eee9851-b07c-4621-a53f-7d0c9b71be2b@github.com>

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

Marked as reviewed by lancea (Reviewer).

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

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

From naoto at openjdk.java.net  Wed Sep 22 15:53:53 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 22 Sep 2021 15:53:53 GMT
Subject: <i18n dev> Integrated: 8273924: ArrayIndexOutOfBoundsException
 thrown in java.util.JapaneseImperialCalendar.add()
In-Reply-To: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
References: <wcqPVoLdsX4Csih31ej4raniVMnJjtPlr49nkUMd26k=.053352ea-9c19-4d54-bd52-f5f43cc6e3b6@github.com>
Message-ID: <BBPsGTXhqDth-C5cx9a6TC2QzfEsCEF31_D8pcqSisA=.c2d60baa-41f2-4441-8042-57fcd99b8f3a@github.com>

On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an AIOOBE on normalizing the month value.

This pull request has now been integrated.

Changeset: d39aad92
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d39aad92308fbc28bd2de164e331062ebf62da85
Stats:     26 lines in 3 files changed: 24 ins; 0 del; 2 mod

8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

Reviewed-by: rriggs, iris, joehw

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

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

From naoto at openjdk.java.net  Thu Sep 23 12:52:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 23 Sep 2021 12:52:03 GMT
Subject: <i18n dev> Integrated: 8273546: DecimalFormat documentation
 contains literal HTML character references
In-Reply-To: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
References: <n-XhN33nvdx7CM1vC_3FvxOTehsPA_mpiGA_RrEx7QQ=.bf929800-b808-41c8-8106-aff313b8a6a0@github.com>
Message-ID: <U-BWNX8mHFZiz-sEkj6Y4OLY89sYimGh0OfbQweAKfY=.17eccea7-ab69-4351-b58b-bae668ece03f@github.com>

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

This pull request has now been integrated.

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

8273546: DecimalFormat documentation contains literal HTML character references

Reviewed-by: joehw, bpb, iris, lancea

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

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

From jpai at openjdk.java.net  Fri Sep 24 14:49:54 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 24 Sep 2021 14:49:54 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem
Message-ID: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>

Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?

As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:

 - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
 - This gives T1 the implicit class init lock on `CalendarSystem`. 
 - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
 - This gives T2 a implicit class init lock on `Gregorian`.
 - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
 - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.

The linked JBS issue has a thread dump which shows this in action.

The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)

A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.

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

Commit messages:
 - 8273790: Potential cyclic dependencies between Gregorian and CalendarSystem

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

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

From naoto at openjdk.java.net  Fri Sep 24 18:00:52 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 24 Sep 2021 18:00:52 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem
In-Reply-To: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
Message-ID: <YxbGpnSunTAlrKz4gb1FTldT4qti-lP7e6Lz8SfRvKc=.3d8980e1-83cf-40a4-b6f0-490d419a532d@github.com>

On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
> 
> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
> 
>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>  - This gives T2 a implicit class init lock on `Gregorian`.
>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
> 
> The linked JBS issue has a thread dump which shows this in action.
> 
> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
> 
> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.

Thanks, Jaikiran. Looks good. Some minor comments.

src/java.base/share/classes/sun/util/calendar/CalendarSystem.java line 123:

> 121:      */
> 122:     public static Gregorian getGregorianCalendar() {
> 123:         var gCal = GREGORIAN_INSTANCE;

Do we need the local variable `gCal`?

test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 43:

> 41:  * @run main/othervm CalendarSystemDeadLockTest
> 42:  * @run main/othervm CalendarSystemDeadLockTest
> 43:  * @run main/othervm CalendarSystemDeadLockTest

Just curious, before the fix, how many test instances caused the deadlock? I'd think these 5 runs are arbitrary numbers, Just wanted to have those 5 runs are appropriate.

test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 75:

> 73:         tasks.add(new GetGregorianCalTask(taskTriggerLatch));
> 74:         tasks.add(new GetGregorianCalTask(taskTriggerLatch));
> 75:         final ExecutorService executor = Executors.newFixedThreadPool(tasks.size());

Asserting `tasks.size() == numTasks` may help here.

test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 171:

> 169:         }
> 170:     }
> 171: }

Need a new line at the EOF.

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

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

From rriggs at openjdk.java.net  Fri Sep 24 18:19:52 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 24 Sep 2021 18:19:52 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem
In-Reply-To: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
Message-ID: <92tcbP0OzS36W8Yjdyv10e8sggxwSNN94FY6p6e8AYM=.ddeaef14-5d44-479c-b65b-da03740a4936@github.com>

On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
> 
> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
> 
>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>  - This gives T2 a implicit class init lock on `Gregorian`.
>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
> 
> The linked JBS issue has a thread dump which shows this in action.
> 
> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
> 
> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.

As an alternative, can the Gregorian Instance be moved to a nested (static) class.
That will delay initialization until it is needed. This "holder" pattern is used elsewhere to defer initialization and break cycles.

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

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

From jpai at openjdk.java.net  Sat Sep 25 03:38:24 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 25 Sep 2021 03:38:24 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem [v2]
In-Reply-To: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
Message-ID: <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
> 
> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
> 
>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>  - This gives T2 a implicit class init lock on `Gregorian`.
>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
> 
> The linked JBS issue has a thread dump which shows this in action.
> 
> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
> 
> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.

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

 - Minor test adjustments as suggested by Naoto
 - use a holder instead of volatile, as suggested by Roger

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5683/files
  - new: https://git.openjdk.java.net/jdk/pull/5683/files/8855f910..8b276d4d

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

  Stats: 22 lines in 2 files changed: 8 ins; 10 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5683/head:pull/5683

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

From jpai at openjdk.java.net  Sat Sep 25 03:48:57 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 25 Sep 2021 03:48:57 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem [v2]
In-Reply-To: <YxbGpnSunTAlrKz4gb1FTldT4qti-lP7e6Lz8SfRvKc=.3d8980e1-83cf-40a4-b6f0-490d419a532d@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
 <YxbGpnSunTAlrKz4gb1FTldT4qti-lP7e6Lz8SfRvKc=.3d8980e1-83cf-40a4-b6f0-490d419a532d@github.com>
Message-ID: <LL_0RoP2tdSgFMBjRC_gFQvOrDyXs_-DFXXWTkDbS94=.27dd0da4-0a18-4dde-a24a-835067ccbc3c@github.com>

On Fri, 24 Sep 2021 17:53:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Minor test adjustments as suggested by Naoto
>>  - use a holder instead of volatile, as suggested by Roger
>
> src/java.base/share/classes/sun/util/calendar/CalendarSystem.java line 123:
> 
>> 121:      */
>> 122:     public static Gregorian getGregorianCalendar() {
>> 123:         var gCal = GREGORIAN_INSTANCE;
> 
> Do we need the local variable `gCal`?

This was there to avoid additional volatile reads in that method. A performance optimization. However, with the change Roger suggested, this is no longer relevant.

> test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 43:
> 
>> 41:  * @run main/othervm CalendarSystemDeadLockTest
>> 42:  * @run main/othervm CalendarSystemDeadLockTest
>> 43:  * @run main/othervm CalendarSystemDeadLockTest
> 
> Just curious, before the fix, how many test instances caused the deadlock? I'd think these 5 runs are arbitrary numbers, Just wanted to have those 5 runs are appropriate.

Hello @naotoj, 
On my setup, without the fix, the test deadlocks almost always right on the first run. There have been cases where it did pass the first time, but running it a second time has always reproduced the failure. The 5 runs that I have in this test is indeed an arbitrary number. Given how quickly this test completes, I decided to use a slightly higher number of 5 instead of maybe 2 or 3. Do you think, we should change the run count to something else?

> test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 75:
> 
>> 73:         tasks.add(new GetGregorianCalTask(taskTriggerLatch));
>> 74:         tasks.add(new GetGregorianCalTask(taskTriggerLatch));
>> 75:         final ExecutorService executor = Executors.newFixedThreadPool(tasks.size());
> 
> Asserting `tasks.size() == numTasks` may help here.

Yes, that makes sense. I've updated the test to add this check.

> test/jdk/sun/util/calendar/CalendarSystemDeadLockTest.java line 171:
> 
>> 169:         }
>> 170:     }
>> 171: }
> 
> Need a new line at the EOF.

Done. I've updated this in the latest version of the PR.

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

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

From jpai at openjdk.java.net  Sat Sep 25 03:52:54 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 25 Sep 2021 03:52:54 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem [v2]
In-Reply-To: <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
 <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
Message-ID: <sfeF3_RqQO38K8Z5anbN5hYLwmEsKbgtN1sKhhlOf_Q=.858dfb7c-f18b-440a-98f4-0c9f5b1364b8@github.com>

On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>> 
>> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
>> 
>>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>>  - This gives T2 a implicit class init lock on `Gregorian`.
>>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
>> 
>> The linked JBS issue has a thread dump which shows this in action.
>> 
>> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
>> 
>> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Minor test adjustments as suggested by Naoto
>  - use a holder instead of volatile, as suggested by Roger

Hello Roger,

> As an alternative, can the Gregorian Instance be moved to a nested (static) class.
That will delay initialization until it is needed. This "holder" pattern is used elsewhere to defer initialization and break cycles.

I did indeed have that in mind when I started work on this. That was something Chris Hegarty had suggested and we have used in a different (but similar) issue a while back[1]. I was however unsure if that's a common enough technique, so had started off with the volatile approach. I've now updated the PR to use the holder technique instead.

[1] https://github.com/openjdk/jdk/pull/2893#issuecomment-797539503

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

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

From yyang at openjdk.java.net  Sat Sep 25 04:42:55 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 25 Sep 2021 04:42:55 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem [v2]
In-Reply-To: <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
 <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
Message-ID: <6pR-Ih_NtVSy0j0d_pX_7SBc0EhW1N5bG9jn7mn65Fg=.9f9f1536-64c2-46db-8a29-540bc19e08ac@github.com>

On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>> 
>> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
>> 
>>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>>  - This gives T2 a implicit class init lock on `Gregorian`.
>>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
>> 
>> The linked JBS issue has a thread dump which shows this in action.
>> 
>> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
>> 
>> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Minor test adjustments as suggested by Naoto
>  - use a holder instead of volatile, as suggested by Roger

@jaikiran Thanks for fixing this. Delaying instance creation via a static holder class seems reasonable to me.

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

Marked as reviewed by yyang (Committer).

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

From github.com+10835776+stsypanov at openjdk.java.net  Sat Sep 25 19:30:31 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: Sat, 25 Sep 2021 19:30:31 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v3]
In-Reply-To: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
Message-ID: <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>

> This is a continuation of
> 
> - https://bugs.openjdk.java.net/browse/JDK-6736490
> - https://bugs.openjdk.java.net/browse/JDK-8035284
> - https://bugs.openjdk.java.net/browse/JDK-8145680
> - https://bugs.openjdk.java.net/browse/JDK-8251548
> 
> As mentioned in JDK-6736490:
> 
> _An explicit initialization of a volatile class instance variable, such as private volatile Object = null; or private volatile int scale = 0; is unnecessary since the Java spec automatically initializes objects to null and primitive type short, int, long, float and double to 0 and boolean to false. Explicit initialization of volatile variable to a value the same as the default implicit initialized value results in an unnecessary store and membar operation._

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

 - Merge branch 'master' into 8272756
 - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop
 - 8272756: Remove unnecessary explicit initialization of volatile fields in java.desktop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5197/files
  - new: https://git.openjdk.java.net/jdk/pull/5197/files/a3558d0a..d13ca900

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

  Stats: 53840 lines in 1699 files changed: 35340 ins; 9612 del; 8888 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5197.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5197/head:pull/5197

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

From serb at openjdk.java.net  Sun Sep 26 21:00:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 26 Sep 2021 21:00:57 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v3]
In-Reply-To: <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <5D1AIPvGtkcbri_67kjwE9GuRe8F4P8A0KZmJ2s68hs=.351bc6fb-b1a6-491d-9cb8-e4738cf7ac2c@github.com>
 <umwDn9Nke1Bnse87ZiQp9k_MyZDXpO45YUFtEXnFU80=.92a2b18b-f32d-4201-94ff-4c75b20e7bd8@github.com>
 <QeTE-KIuatog_Q5dU4BCp8u-U3HarxmHCSfw9uvyEd4=.0ea2627a-d2d5-4185-92cd-2069d9bb3f91@github.com>
 <aQwgzJ4B4oswyjPwlUna8_ccoFwQsnwtUz9TgUCxVmg=.7802c612-eb73-4b5d-b512-6fa6f829cebc@github.com>
 <xVBLj997Laf-N2IwD8dfI2bzfHvtV1P2ji63kXcc10g=.7127c961-2ddb-49e7-a565-4c3351303952@github.com>
Message-ID: <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>

On Mon, 23 Aug 2021 18:31:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I think we can drop it completely.
>
> Agree.

I still suggest to remove the local tag completely.

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

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

From darcy at openjdk.java.net  Mon Sep 27 09:29:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 09:29:09 GMT
Subject: <i18n dev> RFR: 8202056: Expand serial warning to check for bad
 overloads of serial-related methods and ineffectual fields
Message-ID: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>

This is an initial PR for expanded lint warnings done under two bugs:

8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type

to get feedback on the general approach and test strategy before further polishing the implementation.

The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.

Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.

Please also review the corresponding CSRs:

https://bugs.openjdk.java.net/browse/JDK-8274335
https://bugs.openjdk.java.net/browse/JDK-8274336

Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.

The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.

In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

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

Commit messages:
 - Appease jcheck
 - Implement checks chegar recommended for interfaces.
 - Update comment.
 - Add tests for instance field checks.
 - Clean build with instance field checks in place.
 - Merge branch 'master' into JDK-8202056
 - Put Externalizable checks last.
 - Add checks for constructor access in Serializable classes.
 - Add no-arg ctor check for Externalizable classes.
 - Improve Externalization warnings.
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5756385c...d498ff5f

Changes: https://git.openjdk.java.net/jdk/pull/5709/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5709&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202056
  Stats: 1519 lines in 79 files changed: 1511 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5709/head:pull/5709

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

From erikj at openjdk.java.net  Mon Sep 27 13:01:58 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 27 Sep 2021 13:01:58 GMT
Subject: <i18n dev> RFR: 8202056: Expand serial warning to check for bad
 overloads of serial-related methods and ineffectual fields
In-Reply-To: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
References: <6FKZsPgQFbL8ZEFh0EiVXy9QN7o__qNpjvlt4cIJA-I=.2a74a3a6-2a67-425d-bb73-7984b18fc3a4@github.com>
Message-ID: <fleMwIh15sptLebA-p9240UO1uEZArpMzJ2LzaeAOms=.a8932c58-a9ea-45f4-a532-696aecdea5d3@github.com>

On Mon, 27 Sep 2021 01:00:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This is an initial PR for expanded lint warnings done under two bugs:
> 
> 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields
> 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type
> 
> to get feedback on the general approach and test strategy before further polishing the implementation.
> 
> The implementation initially started as an annotation processor I wrote several years ago. The refined version being incorporated into Attr has been refactored, had its checks expanded, and been partially ported to idiomatic javac coding style rather than using the javax.lang.model API from annotation processing.
> 
> Subsequent versions of this PR are expected to move the implementation closer to idiomatic javac, in particular to use javac flags rather than javax.lang.model.Modifier's. Additional resources keys will be defined for the serialization-related fields and methods not having the expected modifiers, types, etc. The resource keys for the existing checks related to serialVersionUID and reused.
> 
> Please also review the corresponding CSRs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8274335
> https://bugs.openjdk.java.net/browse/JDK-8274336
> 
> Informative serialization-related warning messages must take into account whether a class, interface, annotation, record, and enum is being analyzed. Enum classes and record classes have special handling in serialization. This implementation under review has been augmented with checks for interface types recommended by Chris Hegarty in an attachment on 8202056.
> 
> The JDK build has the Xlint:serial check enabled. The build did not pass with the augmented checks. For most modules, this PR contains the library changes necessary for the build to pass. I will start separate PRs in those library areas to get the needed SuppressWarning("serial") or other changes in place. For one module, I temporarily disabled the Xlint:serial check.
> 
> In terms of performance, I have not done benchmarks of the JDK build with and without these changes, but informally the build seems to take about as long as before.

Build change looks ok.

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

Marked as reviewed by erikj (Reviewer).

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

From rriggs at openjdk.java.net  Mon Sep 27 16:42:10 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 27 Sep 2021 16:42:10 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem [v2]
In-Reply-To: <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
 <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
Message-ID: <4ARpOfOEr71m7Kp_h_AE85UzurZLj2KJHV8JhR8M7N4=.550892c2-7c74-4255-b24c-0df9ecc735e7@github.com>

On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>> 
>> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
>> 
>>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>>  - This gives T2 a implicit class init lock on `Gregorian`.
>>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
>> 
>> The linked JBS issue has a thread dump which shows this in action.
>> 
>> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
>> 
>> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Minor test adjustments as suggested by Naoto
>  - use a holder instead of volatile, as suggested by Roger

??

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

Marked as reviewed by rriggs (Reviewer).

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

From naoto at openjdk.java.net  Mon Sep 27 16:42:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 27 Sep 2021 16:42:09 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem [v2]
In-Reply-To: <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
 <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
Message-ID: <qxTAtbQjiHYCZxPQk_Yf0jTYRNW1ex5PmRtqwL9ok24=.dc9d58dd-b57b-44d2-a862-d03995a76338@github.com>

On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>> 
>> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
>> 
>>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>>  - This gives T2 a implicit class init lock on `Gregorian`.
>>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
>> 
>> The linked JBS issue has a thread dump which shows this in action.
>> 
>> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
>> 
>> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Minor test adjustments as suggested by Naoto
>  - use a holder instead of volatile, as suggested by Roger

Looks good. Thank you for the fix!

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

Marked as reviewed by naoto (Reviewer).

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

From darcy at openjdk.java.net  Mon Sep 27 20:31:41 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 20:31:41 GMT
Subject: <i18n dev> RFR: 8274396: Suppress more warnings on non-serializable
 non-transient intance fields in client libs
Message-ID: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>

Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.

The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.

I'll run a script to update the copyright year before pushing.

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

Commit messages:
 - 8274396: Suppress more warnings on non-serializable non-transient instance fields in client libs

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

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

From bpb at openjdk.java.net  Mon Sep 27 20:37:01 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 27 Sep 2021 20:37:01 GMT
Subject: <i18n dev> RFR: 8274396: Suppress more warnings on
 non-serializable non-transient intance fields in client libs
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <Wbq1SuRLPUarncHgqBbxu3VXLNu5JTz-PZBBSbD0wLs=.25f3d183-ce6e-435c-bd59-5b7b2159b135@github.com>

On Mon, 27 Sep 2021 20:21:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

Marked as reviewed by bpb (Reviewer).

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

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

From naoto at openjdk.java.net  Mon Sep 27 21:04:58 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 27 Sep 2021 21:04:58 GMT
Subject: <i18n dev> RFR: 8274396: Suppress more warnings on
 non-serializable non-transient intance fields in client libs
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <vcCCxNX__m_rdZfWPlPd_YxVDtDITOApWZKIkFazzyM=.48f9077a-c97d-4812-9431-af13d6666a08@github.com>

On Mon, 27 Sep 2021 20:21:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

Marked as reviewed by naoto (Reviewer).

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

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

From serb at openjdk.java.net  Mon Sep 27 21:43:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 27 Sep 2021 21:43:01 GMT
Subject: <i18n dev> RFR: 8274396: Suppress more warnings on
 non-serializable non-transient intance fields in client libs
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <2wNXb0TGI4QE3XdISdz0GSPalFjGmiMeb5w9tuG6GKA=.20dd18b0-3eb9-4abe-a75d-ec73f52673cc@github.com>

On Mon, 27 Sep 2021 20:21:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

Can we add comments to SuppressWarnings on why it was added? Previously we use this text
> // Not statically typed as Serializable

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

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

From darcy at openjdk.java.net  Mon Sep 27 22:48:24 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 22:48:24 GMT
Subject: <i18n dev> RFR: 8274396: Suppress more warnings on
 non-serializable non-transient intance fields in client libs [v2]
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

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

  Add comments requested in code review.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5723/files
  - new: https://git.openjdk.java.net/jdk/pull/5723/files/ab72612d..2977d859

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

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

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

From darcy at openjdk.java.net  Mon Sep 27 22:55:00 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 27 Sep 2021 22:55:00 GMT
Subject: <i18n dev> RFR: 8274396: Suppress more warnings on
 non-serializable non-transient intance fields in client libs
In-Reply-To: <2wNXb0TGI4QE3XdISdz0GSPalFjGmiMeb5w9tuG6GKA=.20dd18b0-3eb9-4abe-a75d-ec73f52673cc@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
 <2wNXb0TGI4QE3XdISdz0GSPalFjGmiMeb5w9tuG6GKA=.20dd18b0-3eb9-4abe-a75d-ec73f52673cc@github.com>
Message-ID: <MyP2PU_B6BufARDaonSXrINBGn1kRsQoY1widUwx3ro=.fe3b0be5-01fd-41e4-8a63-2eb64602a089@github.com>

On Mon, 27 Sep 2021 21:40:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> 
> 
> Can we add comments to SuppressWarnings on why it was added? Previously we use this text
> 
> > // Not statically typed as Serializable

Added in revision; used a different comment wording.

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

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

From serb at openjdk.java.net  Tue Sep 28 01:24:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 28 Sep 2021 01:24:01 GMT
Subject: <i18n dev> RFR: 8274396: Suppress more warnings on
 non-serializable non-transient intance fields in client libs [v2]
In-Reply-To: <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
 <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>
Message-ID: <jgBmqZjco39xUzmpvOeATPUAGMrw6PFAiwRuh6F4hqE=.79d6521b-11e1-47a4-a379-a6df089829df@github.com>

On Mon, 27 Sep 2021 22:48:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
>> 
>> I'll run a script to update the copyright year before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments requested in code review.

Marked as reviewed by serb (Reviewer).

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

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

From jpai at openjdk.java.net  Tue Sep 28 05:06:02 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 28 Sep 2021 05:06:02 GMT
Subject: <i18n dev> Integrated: 8273790: Potential cyclic dependencies
 between Gregorian and CalendarSystem
In-Reply-To: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
Message-ID: <7Z6OSZMJfziq2kZyz68yzST4yq4OjyalBdgq1gi2o1A=.1073dbe4-d2c1-4d7b-a691-54b22b02f1f9@github.com>

On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
> 
> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
> 
>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>  - This gives T2 a implicit class init lock on `Gregorian`.
>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
> 
> The linked JBS issue has a thread dump which shows this in action.
> 
> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
> 
> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.

This pull request has now been integrated.

Changeset: ddc26274
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ddc262746aea99050b9a6484f51c7ddb8f4bc991
Stats:     183 lines in 2 files changed: 179 ins; 0 del; 4 mod

8273790: Potential cyclic dependencies between Gregorian and CalendarSystem

Reviewed-by: naoto, yyang, rriggs

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

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

From jpai at openjdk.java.net  Tue Sep 28 05:05:59 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 28 Sep 2021 05:05:59 GMT
Subject: <i18n dev> RFR: 8273790: Potential cyclic dependencies between
 Gregorian and CalendarSystem [v2]
In-Reply-To: <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
References: <z4Zh9a3YZJm1YfIDxMDrUKZ4qF6tUQkuPD23_c1OS-I=.12fc970d-f88d-412e-a4d6-f8fa9b101def@github.com>
 <ec3ZwWuexLuUGIj1pSToxHuGqHT-vDJ_bi30yH2XnRY=.dbeb9cdb-2595-4815-ac42-fba12782ed92@github.com>
Message-ID: <mAfNgIac1FTET-Rq_4d7Uq_v7u2epFt3tXOAYfYHpiU=.7f2f70e2-acf9-4a7b-8b20-c00b22d1244f@github.com>

On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>> 
>> As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to a deadlock because of the cyclic nature of the code in their static initialization. More specifically, consider this case:
>> 
>>  - Thread T1 initiates a classload on the `sun.util.calendar.CalendarSystem`.
>>  - This gives T1 the implicit class init lock on `CalendarSystem`. 
>>  - Consider thread T2 which at the same time initiates a classload on `sun.util.calendar.Gregorian` class.
>>  - This gives T2 a implicit class init lock on `Gregorian`.
>>  - T1, still holding a lock on `CalendarSystem` attempts to load `Gregorian` since it wants to create a (singleton) instance of `Gregorian` and assign it to the `static final GREGORIAN_INSTANCE` member. Since T2 is holding a class init lock on `Gregorian`, T1 ends up waiting
>>  - T2 on the other hand is still loading the `Gregorian` class. `Gregorian` itself "is a" `CalendarSystem`, so during this loading of `Gregorian` class, T2 starts travelling up the class hierarchy and asks for a lock on `CalendarSystem`. However T1 is holding this lock and as a result T2 ends up waiting on T1 which is waiting on T2. That triggers this deadlock.
>> 
>> The linked JBS issue has a thread dump which shows this in action.
>> 
>> The commit here delays the instance creation of `Gregorian` by moving that instance creation logic from the static initialization of the `CalendarSystem` class, to the first call to `CalendarSystem#getGregorianCalendar()`. This prevents the `CalendarSystem` from needing a lock on `Gregorian` during its static init (of course, unless some code in this static init flow calls `CalendarSystem#getGregorianCalendar()`, in which case it is back to square one. I have verified, both manually and through the jtreg test, that the code in question doesn't have such calls)
>> 
>> A new jtreg test has been introduced to reproduce the issue and verify the fix. The test in addition to loading these 2 classes in question, also additionally loads a few other classes concurrently. These classes have specific static initialization which leads the calls to `CalendarSystem#getGregorianCalendar()` or `CalendarSystem#forName()`. Including these classes in the tests ensures that this deadlock hasn't "moved" to a different location. I have run multiple runs (approximately 25) of this test with the fix and I haven't seen it deadlock anymore.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Minor test adjustments as suggested by Naoto
>  - use a holder instead of volatile, as suggested by Roger

Thank you Roger, Naoto and Yi Yang for the reviews.

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

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

From y.umaoka at gmail.com  Tue Sep 28 15:34:56 2021
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Tue, 28 Sep 2021 11:34:56 -0400
Subject: <i18n dev> TZ database 2021b changes
Message-ID: <eb875703-c047-c009-f2ca-69f7705adbc5@gmail.com>

Hello OpenJDK i18n dev team,

As you may already know, TZ database 2021b was released last week, and 
it contains some drastic changes for pre-1970 rules. Multiple zones 
sharing post 1970 rules were merged into one, and they were moved to 
backward file. Pre-1970 rules used for these merged zones in 2021a were 
in backzone file, but it's not a part of standard package.

In the tz mailing list, many TZ database consumers are worrying about 
this move. It looks not a small number of people are against this 
change, and some are considering to maintain database separately to 
maintain rules for pre-1970 dates.

I'm curious about what Java i18n team will do for this. Do you plan to 
accept the changes done in TZ database 2021b as-is? Or do you plan to 
preserve rules in backzone?

We discussed this topic in Unicode ICU team meeting last week. We don't 
have long term strategy yet. However, DST change in Samoa is already in 
effect, we're going to ship a quick patch including 2021b zone rule 
updates applied on top of 2021a for now (today or tomorrow).

-Yoshito


From iris at openjdk.java.net  Tue Sep 28 16:49:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 28 Sep 2021 16:49:39 GMT
Subject: <i18n dev> RFR: 8274396: Suppress more warnings on
 non-serializable non-transient intance fields in client libs [v2]
In-Reply-To: <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
 <TjAmogSCchLUCmS82lhXQIyjfY5mI1D-AbmjIuWiDLM=.6e56fa04-ccb3-4050-a296-c612e90ff7ff@github.com>
Message-ID: <ZzOlWQM5GpIOS60QEV8ThLdWVrZfsiB8You4ZhVC_TY=.3c992318-53ea-4b48-a1ec-e517bc2ea253@github.com>

On Mon, 27 Sep 2021 22:48:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
>> 
>> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
>> 
>> I'll run a script to update the copyright year before pushing.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments requested in code review.

I like the comments indicating why the suppression is needed.

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

Marked as reviewed by iris (Reviewer).

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

From darcy at openjdk.java.net  Tue Sep 28 21:52:34 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 28 Sep 2021 21:52:34 GMT
Subject: <i18n dev> Integrated: 8274396: Suppress more warnings on
 non-serializable non-transient instance fields in client libs
In-Reply-To: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
References: <Oqj_kkCkweOxb7chSu0Sa7BdBwgZTDkxM6yQ-5YXDzE=.b8d12543-0b7c-4dfd-8cb3-0bdeb5d15f3f@github.com>
Message-ID: <37-3BkyxsYsQhemuIIOHxDakn_z4a-u_Kek_rZQ4Rao=.f168c9b5-e3cd-4c67-ad02-577cd629049f@github.com>

On Mon, 27 Sep 2021 20:21:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Follow-up changes to JDK-8231334. , augmentations to javac's Xlint:serial checking are out for review (#5709) and various client libraries would need some changes to pass under the expanded checks.
> 
> The changes are to suppress warnings where non-transient fields in serializable types are not declared with a type statically known to be serializable. That isn't necessarily a correctness issues, but it does merit further scrutiny.
> 
> I'll run a script to update the copyright year before pushing.

This pull request has now been integrated.

Changeset: d8a278f3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d8a278f3948e9a5c881e64cce0a588e31246a4b5
Stats:     7 lines in 5 files changed: 7 ins; 0 del; 0 mod

8274396: Suppress more warnings on non-serializable non-transient instance fields in client libs

Reviewed-by: bpb, naoto, serb, iris

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

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

From naoto.sato at oracle.com  Thu Sep 30 17:33:52 2021
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 30 Sep 2021 10:33:52 -0700
Subject: <i18n dev> TZ database 2021b changes
In-Reply-To: <eb875703-c047-c009-f2ca-69f7705adbc5@gmail.com>
References: <eb875703-c047-c009-f2ca-69f7705adbc5@gmail.com>
Message-ID: <6f155832-ad73-5383-eb06-21262f7cae43@oracle.com>

Hi Yoshito,

We at Oracle had discussed this, but still have not yet decided the 
direction. We have an issue to upgrade the JDK for 2021b:

https://bugs.openjdk.java.net/browse/JDK-8274407

I will update the issue as things are decided.

Naoto

On 9/28/21 8:34 AM, Yoshito Umaoka wrote:
> Hello OpenJDK i18n dev team,
> 
> As you may already know, TZ database 2021b was released last week, and 
> it contains some drastic changes for pre-1970 rules. Multiple zones 
> sharing post 1970 rules were merged into one, and they were moved to 
> backward file. Pre-1970 rules used for these merged zones in 2021a were 
> in backzone file, but it's not a part of standard package.
> 
> In the tz mailing list, many TZ database consumers are worrying about 
> this move. It looks not a small number of people are against this 
> change, and some are considering to maintain database separately to 
> maintain rules for pre-1970 dates.
> 
> I'm curious about what Java i18n team will do for this. Do you plan to 
> accept the changes done in TZ database 2021b as-is? Or do you plan to 
> preserve rules in backzone?
> 
> We discussed this topic in Unicode ICU team meeting last week. We don't 
> have long term strategy yet. However, DST change in Samoa is already in 
> effect, we're going to ship a quick patch including 2021b zone rule 
> updates applied on top of 2021a for now (today or tomorrow).
> 
> -Yoshito
> 

From naoto at openjdk.java.net  Thu Sep 30 21:48:27 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 30 Sep 2021 21:48:27 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were grabled
 on Japanese Windows
In-Reply-To: <YCW8f5kU2eVwv6IMrXl2czyQOG0R-UydRDRTAJuC-TA=.e1dc8088-bd67-432e-b578-49f2b86d313e@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <YCW8f5kU2eVwv6IMrXl2czyQOG0R-UydRDRTAJuC-TA=.e1dc8088-bd67-432e-b578-49f2b86d313e@github.com>
Message-ID: <ZW0SB1OfPLeYapQV6_2eYznNZxKO9_wU4A3JdiDbrnE=.706dbebc-e95d-4a03-a58f-95136e3d00e9@github.com>

On Thu, 30 Sep 2021 10:10:31 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> * Using native.encoding system property. But test/langtools/tools/javac/diags/CheckResourceKeys.java was failed.

What was the cause of the failure?

> * Use java.io.Console, like Console cons = System.console() and cons.charset(), but "javac 2>&1 | more" does not work as expected because System.console() returns null.
> 
> So I added -Dfile.encoding=COMPAT expect java and javaw commands on launcher.

I think we should fix the root cause of this, instead of specifying `file.encoding=COMPAT`

> 
> jshell does not work as expected on b12

Do you mean `b13`?

> 
> ```
> >jdk-18-b12\bin\jshell.exe
> |  JShell????? -- ?????18-ea
> |  ??????????????????: /help intro
> 
> jshell> "\u3042".getBytes()
> $1 ==> byte[2] { -126, -96 }
> ```
> 
> on b13
> 
> ```
> >jdk-18-b13\bin\jshell.exe
> |  JShell????? -- ?????18-ea
> |  ??????????????????: /help intro
> 
> jshell> "\u3042".getBytes()
> $1 ==> byte[3] { -29, -127, -126 }
> ```
> 
> It's UTF-8, not native encoding. I think backend java process should use same fine.encoding system property setting.

No it should not. `file.encoding` should not be inherited.

Naoto

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

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