From itakiguchi at openjdk.java.net  Fri Oct  1 02:07:41 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 1 Oct 2021 02:07:41 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were grabled
 on Japanese Windows
In-Reply-To: <ZW0SB1OfPLeYapQV6_2eYznNZxKO9_wU4A3JdiDbrnE=.706dbebc-e95d-4a03-a58f-95136e3d00e9@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <YCW8f5kU2eVwv6IMrXl2czyQOG0R-UydRDRTAJuC-TA=.e1dc8088-bd67-432e-b578-49f2b86d313e@github.com>
 <ZW0SB1OfPLeYapQV6_2eYznNZxKO9_wU4A3JdiDbrnE=.706dbebc-e95d-4a03-a58f-95136e3d00e9@github.com>
Message-ID: <F5lLlELhmmwih0zVqKTYmG8HQtXYJ3ZeY2NFuepIppo=.2dc73bb3-2963-445b-9f6b-1d70d49fdf0d@github.com>

On Thu, 30 Sep 2021 21:45:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Screenshot
>> ![javac-screenshot](https://user-images.githubusercontent.com/33543753/135429041-0ed22b36-0b1e-4626-92ca-8b58acf8872d.png)
>> 
>> javac does not use PrintStream for standard out/err, it uses PrintWriter.
>> I put some codes on src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
>> * Using native.encoding system property. But test/langtools/tools/javac/diags/CheckResourceKeys.java was failed.
>> * 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.
>> 
>> jshell does not work as expected on b12
>> 
>>>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.
>> 
>> I don't think it's good fix, so please give me some advices.
>
>> * 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

@naotoj 
I applied following change on src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
@@ -26,6 +26,7 @@
 package com.sun.tools.javac.util;

 import java.io.*;
+import java.nio.charset.Charset;
 import java.util.Arrays;
 import java.util.EnumMap;
 import java.util.EnumSet;
@@ -261,12 +262,22 @@ public class Log extends AbstractLog {
      * @param context the context in which to find writers to use
      * @return a map of writers
      */
+    private final static Charset nativeCharset;
+    static {
+        Charset cs = Charset.defaultCharset();
+        try {
+            cs = Charset.forName(System.getProperty("native.encoding"));
+        } catch (Exception e) {
+        }
+        nativeCharset = cs;
+    }
+
     private static Map<WriterKind, PrintWriter> initWriters(Context context) {
         PrintWriter out = context.get(outKey);
         PrintWriter err = context.get(errKey);
         if (out == null && err == null) {
-            out = new PrintWriter(System.out, true);
-            err = new PrintWriter(System.err, true);
+            out = new PrintWriter(System.out, true, nativeCharset);
+            err = new PrintWriter(System.err, true, nativeCharset);
             return initWriters(out, err);
         } else if (out == null || err == null) {
             PrintWriter pw = (out != null) ? out : err;


I got following exception via tools/javac/diags/CheckResourceKeys.java

Error: no match for "native.encoding"
java.lang.Exception: 1 errors occurred
        at CheckResourceKeys.main(CheckResourceKeys.java:59)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:833)

About jshell, my sample was not good,
See this one.
By b12

>jdk-18-b12\bin\jshell
|  JShell????? -- ?????18-ea
|  ??????????????????: /help intro

jshell> System.out.println("\u3042")
?

By b13

>jdk-18-b13\bin\jshell
|  JShell????? -- ?????18-ea
|  ??????????????????: /help intro

jshell> System.out.println("\u3042")
??

By b13 with file.encoding=COMPAT

>jdk-18-b13\bin\jshell -J-Dfile.encoding=COMPAT
|  JShell????? -- ?????18-ea
|  ??????????????????: /help intro

jshell> System.out.println("\u3042")
??

If I need to create another issue, please let me know.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  1 11:54:55 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 1 Oct 2021 11:54:55 GMT
Subject: <i18n dev> RFR: 8274640: Cleanup unnecessary null comparison before
 instanceof check in java.desktop
Message-ID: <n5S1rzozHGC53h8iD9YhzAYZWL5MXZeFO1OHIrtkvGc=.cb9eaf1e-da3f-4f81-937f-ec6d1f74aac0@github.com>

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

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

Commit messages:
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.desktop

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

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

From jlahoda at openjdk.java.net  Fri Oct  1 11:59:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 1 Oct 2021 11:59:32 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were grabled
 on Japanese Windows
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <EzaYnChPxAGq05OMnqvx2H4rohzDRIIEIVGxVwKxMfo=.e503ce07-c96b-4e13-9b3b-1c78c08ed93e@github.com>

On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

Regarding javac, the patch to `Log.java` seems to be in a reasonable direction: the write is to the physical `System.out/err` which should be done(?) using the native encoding. The order of the changed lines should be fixed, so that the javadoc is kept above the `initWriters` method. (As a secondary comment, it maybe a matter of discussion on whether keeping the native encoding in a static field is warranted here, but I don't mind it much.)

Regarding JShell, I guess I need to try to find a way to reproduce for me, so that I can debug. AFAIK the main process does not read/write from/to the console using `System.in`/`System.out`, so encoding plays no real role for the console, but it plays role in the communication between the agent and the main process.

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

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

From prappo at openjdk.java.net  Fri Oct  1 12:16:27 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 1 Oct 2021 12:16:27 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were grabled
 on Japanese Windows
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <Mv-M8w6R7qV5XoJ9qbt_iku843Sn84i8kGK8aHWfEFo=.0adeaef2-4ef3-4efb-a7f3-84ecf9f16f60@github.com>

On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

For searchability, you could fix the typo in the PR title and JBS summary: grABled -> gARbled. A nit, really.

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

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

From jlahoda at openjdk.java.net  Fri Oct  1 12:24:27 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 1 Oct 2021 12:24:27 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows
In-Reply-To: <EzaYnChPxAGq05OMnqvx2H4rohzDRIIEIVGxVwKxMfo=.e503ce07-c96b-4e13-9b3b-1c78c08ed93e@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <EzaYnChPxAGq05OMnqvx2H4rohzDRIIEIVGxVwKxMfo=.e503ce07-c96b-4e13-9b3b-1c78c08ed93e@github.com>
Message-ID: <QjMMeENakyxRl-hTmLx95aylGyubGCELhU1m4PPw7Es=.af7083ed-e4d3-4a2e-945a-d0954ee0d6ef@github.com>

On Fri, 1 Oct 2021 11:56:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Regarding javac, the patch to `Log.java` seems to be in a reasonable direction: the write is to the physical `System.out/err` which should be done(?) using the native encoding. The order of the changed lines should be fixed, so that the javadoc is kept above the `initWriters` method. (As a secondary comment, it maybe a matter of discussion on whether keeping the native encoding in a static field is warranted here, but I don't mind it much.)

I've forgot to write a note on the test, sorry: simply add `native.encoding` into `noResourceRequired` set in the test. The test checks that there are not hardcoded string that should be part of the resource bundle (and the resource bundle does not have unused keys), but names of system properties should be excluded, which is what the `noResourceRequired` set does.

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

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

From itakiguchi at openjdk.java.net  Fri Oct  1 12:33:30 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 1 Oct 2021 12:33:30 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows
In-Reply-To: <Mv-M8w6R7qV5XoJ9qbt_iku843Sn84i8kGK8aHWfEFo=.0adeaef2-4ef3-4efb-a7f3-84ecf9f16f60@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <Mv-M8w6R7qV5XoJ9qbt_iku843Sn84i8kGK8aHWfEFo=.0adeaef2-4ef3-4efb-a7f3-84ecf9f16f60@github.com>
Message-ID: <1IiimjjvBmQMekEbl91o0xEHlqxd8TYIPKuWf3phIUI=.6c630a04-050a-48f0-955e-823f6bd84417@github.com>

On Fri, 1 Oct 2021 12:13:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> For searchability, you could fix the typo in the PR title and JBS summary: grABled -> gARbled. A nit, really.

@pavelrappo Many thanks.
I changed PR and JBS.

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

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

From naoto at openjdk.java.net  Fri Oct  1 18:17:27 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 1 Oct 2021 18:17:27 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <mj2Zsi5XXXFMxPV34Myy5FAdQILPuIKrmVtbh--dKQc=.8b5bba0d-f1b6-4f3b-bfe6-79592350f415@github.com>

On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

The encoding used in `Log.java` should first check whether it is run within console or not. If `System.console()` returns the console, its `.charset()` should be used instead of `native.encoding` value.
As to the jshell issue, it is a different issue than javac, so I would expect it to be handled with a different issue.

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

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

From naoto at openjdk.java.net  Fri Oct  1 19:04:47 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 1 Oct 2021 19:04:47 GMT
Subject: <i18n dev> RFR: 8274658: ISO 4217 Amendment #170 Update
Message-ID: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com>

This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately.

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

Commit messages:
 - 8274658: ISO 4217 Amendment #170 Update

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

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

From lancea at openjdk.java.net  Fri Oct  1 20:06:27 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 1 Oct 2021 20:06:27 GMT
Subject: <i18n dev> RFR: 8274658: ISO 4217 Amendment #170 Update
In-Reply-To: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com>
References: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com>
Message-ID: <nzp7Ig9Wh4w0luDmNu7Xtp6pQAY4hEEJe4Agyw3U2xY=.01a56096-a7d2-4ea7-ab55-456b03cc8781@github.com>

On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately.

Marked as reviewed by lancea (Reviewer).

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

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

From iris at openjdk.java.net  Sat Oct  2 02:44:30 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Sat, 2 Oct 2021 02:44:30 GMT
Subject: <i18n dev> RFR: 8274658: ISO 4217 Amendment 170 Update
In-Reply-To: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com>
References: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com>
Message-ID: <c-xTaEcQleIjyJeNNbf5np0h1G2AIwcz6Ta9EaugRx8=.a2fa7193-5259-4b57-877f-fb874583e91f@github.com>

On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately.

Marked as reviewed by iris (Reviewer).

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

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

From itakiguchi at openjdk.java.net  Mon Oct  4 07:13:37 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 4 Oct 2021 07:13:37 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v2]
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <TyMEXFLaE9N24VYfH1QkjM-EN5KfW0W5yJqhZoVPk-k=.791ada4a-357d-4d25-8efe-d80bb2c24af5@github.com>

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

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

  8274544: Langtools command's usage were garbled on Japanese Windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5771/files
  - new: https://git.openjdk.java.net/jdk/pull/5771/files/f348c26e..bfe90241

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

  Stats: 194 lines in 11 files changed: 141 ins; 34 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771

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

From itakiguchi at openjdk.java.net  Mon Oct  4 08:50:12 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 4 Oct 2021 08:50:12 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows
In-Reply-To: <mj2Zsi5XXXFMxPV34Myy5FAdQILPuIKrmVtbh--dKQc=.8b5bba0d-f1b6-4f3b-bfe6-79592350f415@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mj2Zsi5XXXFMxPV34Myy5FAdQILPuIKrmVtbh--dKQc=.8b5bba0d-f1b6-4f3b-bfe6-79592350f415@github.com>
Message-ID: <B2epwQChX5YEaeLM9JwcX3H35Aonyz6reMNo6ovFhDw=.9b7dcec4-44b3-4f45-aa9c-d8118cc44387@github.com>

On Fri, 1 Oct 2021 18:14:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> The encoding used in `Log.java` should first check whether it is run within console or not. If `System.console()` returns the console, its `.charset()` should be used instead of `native.encoding` value.
> As to the jshell issue, it is a different issue than javac, so I would expect it to be handled with a different issue.

Helllo @naotoj .
I used `System.console()` and `Console.charset()`.

The following executables had same issue, I fixed them.
> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe

I could not find out the following executables had same issue or not
> jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe

The following executables worked fine.
> jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe

The following executables were GUI apps
> jaccessinspector.exe, jaccesswalker.exe, jconsole.exe

These fixes don't have testcases.
Do you have any idea about testcase for this issue ?

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

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

From jlahoda at openjdk.java.net  Mon Oct  4 10:27:08 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 4 Oct 2021 10:27:08 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows
In-Reply-To: <B2epwQChX5YEaeLM9JwcX3H35Aonyz6reMNo6ovFhDw=.9b7dcec4-44b3-4f45-aa9c-d8118cc44387@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mj2Zsi5XXXFMxPV34Myy5FAdQILPuIKrmVtbh--dKQc=.8b5bba0d-f1b6-4f3b-bfe6-79592350f415@github.com>
 <B2epwQChX5YEaeLM9JwcX3H35Aonyz6reMNo6ovFhDw=.9b7dcec4-44b3-4f45-aa9c-d8118cc44387@github.com>
Message-ID: <kKgu64ppJfgbqLlBu4G-yis4_KfE66OeUdIdnqV-YPk=.3514a1d7-5aa4-4897-9924-a4b52f321484@github.com>

On Mon, 4 Oct 2021 08:47:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> The encoding used in `Log.java` should first check whether it is run within console or not. If `System.console()` returns the console, its `.charset()` should be used instead of `native.encoding` value.
>> As to the jshell issue, it is a different issue than javac, so I would expect it to be handled with a different issue.
>
> Helllo @naotoj .
> I used `System.console()` and `Console.charset()`.
> 
> The following executables had same issue, I fixed them.
>> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe
> 
> I could not find out the following executables had same issue or not
>> jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe
> 
> The following executables worked fine.
>> jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe
> 
> The following executables were GUI apps
>> jaccessinspector.exe, jaccesswalker.exe, jconsole.exe
> 
> These fixes don't have testcases.
> Do you have any idea about testcase for this issue ?

@takiguc - if JShell is still an issue, is there a chance you could try this:
https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686

Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console.

Thanks!

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

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

From azvegint at openjdk.java.net  Mon Oct  4 15:09:16 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 4 Oct 2021 15:09:16 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
Message-ID: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>

This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

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

Commit messages:
 - rewording
 - initial

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

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

From naoto at openjdk.java.net  Mon Oct  4 15:10:13 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 4 Oct 2021 15:10:13 GMT
Subject: <i18n dev> Integrated: 8274658: ISO 4217 Amendment 170 Update
In-Reply-To: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com>
References: <7zuKEb7vzszIUU9VGj6c_VZRqsDhtyTSwvjDXL6b3TY=.e792b2b2-73cf-4c38-8d7c-88dc6405f9ea@github.com>
Message-ID: <HfQZHn8ARPLOJHUqoGHqEHr_m0vwrQ8MZHOCVT09i7w=.141dc6a8-d144-4c11-85db-4fd386dde634@github.com>

On Fri, 1 Oct 2021 18:57:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to incorporate the ISO 4217 amendment #170, which has been released today, effective immediately.

This pull request has now been integrated.

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

8274658: ISO 4217 Amendment 170 Update

Reviewed-by: lancea, iris

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

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

From naoto at openjdk.java.net  Mon Oct  4 16:44:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 4 Oct 2021 16:44:09 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v2]
In-Reply-To: <TyMEXFLaE9N24VYfH1QkjM-EN5KfW0W5yJqhZoVPk-k=.791ada4a-357d-4d25-8efe-d80bb2c24af5@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <TyMEXFLaE9N24VYfH1QkjM-EN5KfW0W5yJqhZoVPk-k=.791ada4a-357d-4d25-8efe-d80bb2c24af5@github.com>
Message-ID: <HWbHjhmiGNwsEJI-pR4nkVlOjdumW3DBgd2ZgZtGQLo=.5ff2abe8-db02-4597-b370-49bad7c80e96@github.com>

On Mon, 4 Oct 2021 07:13:37 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274544: Langtools command's usage were garbled on Japanese Windows

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 265:

> 263:      * @return a map of writers
> 264:      */
> 265:     private final static Charset nativeCharset;

Inserting this static initializer in the middle of a method, between its javadoc and impl, is odd.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 267:

> 265:     private final static Charset nativeCharset;
> 266:     static {
> 267:         Charset cs = Charset.defaultCharset();

This could move into the `catch` section as a last resort.

src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 419:

> 417:             return new PrintWriter(System.err, true, nativeCharset);
> 418:         } else {
> 419:             if (s.equals((OutputStream)System.err) || s.equals((OutputStream)System.out)) {

Can we use `==` here?

src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java line 50:

> 48:      * @param args command line arguments
> 49:      */
> 50:     private final static Charset nativeCharset;

Static initializer dissecting main method (javadoc/impl)

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

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

From serb at openjdk.java.net  Mon Oct  4 17:28:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 17:28:09 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>

On Mon, 4 Oct 2021 14:54:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

If the problem is in the validation of the parameters maybe we can enforce it?

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

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

From azvegint at openjdk.java.net  Mon Oct  4 18:11:06 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 4 Oct 2021 18:11:06 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>
Message-ID: <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>

On Mon, 4 Oct 2021 17:25:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If the problem is in the validation of the parameters maybe we can enforce it?

It is one of possible solutions. 
Also we have a following javadoc:



    /**
     * Constructs an InputContext.
     * This method is protected so clients cannot instantiate
     * InputContext directly. Input contexts are obtained by
     * calling {@link #getInstance}.
     */
    protected InputContext() {

So those validation of the parameters enforcements will be an almost dead code, only used by synthetic specification test.

Another solution is to make this class abstract.

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

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

From serb at openjdk.java.net  Mon Oct  4 18:20:18 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 18:20:18 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>
 <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>
Message-ID: <7-5hGeRQVGJzHNP7XzuVvrG2Gf03CEUjAmIqJBgtEGc=.5531a550-e96c-4baf-a76b-367b813ef4a6@github.com>

On Mon, 4 Oct 2021 18:07:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Another solution is to make this class abstract.

It won't help, since they will subclass this class and call the parent methods, which they do a few times already for some other cases.

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

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

From serb at openjdk.java.net  Mon Oct  4 18:26:16 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 4 Oct 2021 18:26:16 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <5o3brNWAUIPHurnnBS3bcuus_9fQwTLc5g3nUTkSA5Y=.ced390ad-d751-4bb7-ad60-d1927e9cb062@github.com>
 <aTwn8PCU8sRsLsSZUza5C5CAMrxjj6HlynFLL9gE5bY=.1cabd115-2969-48d1-9d7b-30c5332de197@github.com>
Message-ID: <u1OodZcXP4jOXJ-abZj1BYNGj2JlU1ZWsuVRde8KZ5A=.fcde7820-802e-44f4-a04c-d15b2014a794@github.com>

On Mon, 4 Oct 2021 18:07:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> So those validation of the parameters enforcements will be an almost dead code, only used by synthetic specification test.

But is it worth it to update the spec in stone that these methods will return null/false/no-exceptions forever just because of one synthetic specification test?

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

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

From naoto at openjdk.java.net  Mon Oct  4 20:19:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 4 Oct 2021 20:19:08 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <wnkZxd_5tta66XeulIK3uF1boXhDKTh_uCkopyct0ug=.f4e6bbcc-6a46-4ffe-a78f-0ce319c91608@github.com>

On Mon, 4 Oct 2021 14:54:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

I'd agree we add clarification to the spec, instead of adding parameter checks. Java input methods became less useful after JDK9, where it restricted system-wide Java IM installation (The extension mechanism was removed).

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

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

From itakiguchi at openjdk.java.net  Tue Oct  5 16:04:11 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 5 Oct 2021 16:04:11 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows
In-Reply-To: <kKgu64ppJfgbqLlBu4G-yis4_KfE66OeUdIdnqV-YPk=.3514a1d7-5aa4-4897-9924-a4b52f321484@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mj2Zsi5XXXFMxPV34Myy5FAdQILPuIKrmVtbh--dKQc=.8b5bba0d-f1b6-4f3b-bfe6-79592350f415@github.com>
 <B2epwQChX5YEaeLM9JwcX3H35Aonyz6reMNo6ovFhDw=.9b7dcec4-44b3-4f45-aa9c-d8118cc44387@github.com>
 <kKgu64ppJfgbqLlBu4G-yis4_KfE66OeUdIdnqV-YPk=.3514a1d7-5aa4-4897-9924-a4b52f321484@github.com>
Message-ID: <7Z2FjetdPfBfn1huJa-d1ZteNfOVjYmO5RSLFVrhJmA=.d22a8320-0337-4c25-959a-0e99ac8667ff@github.com>

On Mon, 4 Oct 2021 10:24:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Helllo @naotoj .
>> I used `System.console()` and `Console.charset()`.
>> 
>> The following executables had same issue, I fixed them.
>>> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe
>> 
>> I could not find out the following executables had same issue or not
>>> jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe
>> 
>> The following executables worked fine.
>>> jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe
>> 
>> The following executables were GUI apps
>>> jaccessinspector.exe, jaccesswalker.exe, jconsole.exe
>> 
>> These fixes don't have testcases.
>> Do you have any idea about testcase for this issue ?
>
> @takiguc - if JShell is still an issue, is there a chance you could try this:
> https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686
> 
> Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console.
> 
> Thanks!

Thanks, @lahodaj .
I opened [JDK-8274784](https://bugs.openjdk.java.net/browse/JDK-8274784).

I tested your code, it worked fine on standard case !
Many thanks.

But, to execute previous saved command list, user needs to specify -J-Dfile.encoding=COMPAT and -R-Dfile.encoding=COMPAT options.
Do you have any idea about this kind of case ?

I'd like to discuss jshell things by [JDK-8274784](https://bugs.openjdk.java.net/browse/JDK-8274784).

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

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

From naoto at openjdk.java.net  Wed Oct  6 00:06:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Oct 2021 00:06:06 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v2]
In-Reply-To: <TyMEXFLaE9N24VYfH1QkjM-EN5KfW0W5yJqhZoVPk-k=.791ada4a-357d-4d25-8efe-d80bb2c24af5@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <TyMEXFLaE9N24VYfH1QkjM-EN5KfW0W5yJqhZoVPk-k=.791ada4a-357d-4d25-8efe-d80bb2c24af5@github.com>
Message-ID: <LRnl9i-pqu67p1ifZGSaJWipAnDh28JrwTeoOeK4r7A=.a5b8157f-3ef3-47b2-8718-361b00261e03@github.com>

On Mon, 4 Oct 2021 07:13:37 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274544: Langtools command's usage were garbled on Japanese Windows

I just grepped `System.out/err` in jshell source directory, and found another location in `tool/JShellToolProvider.java` that uses bare stdout/err. Would you also apply the fix and see the result?

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

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

From naoto at openjdk.java.net  Wed Oct  6 03:17:27 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Oct 2021 03:17:27 GMT
Subject: <i18n dev> RFR: 8274407: (tz) Update Timezone Data to 2021c
Message-ID: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>

This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted.
The PR also fixes two issues along with the 2021c upgrade.

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

Commit messages:
 - Fix for Asia/Amman test case error
 - Test fix for Samoa not observing DST
 - tzdata2021c
 - 8274407: (tz) Update Timezone Data to 2021b

Changes: https://git.openjdk.java.net/jdk/pull/5832/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5832&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274407
  Stats: 635 lines in 13 files changed: 228 ins; 329 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5832/head:pull/5832

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

From itakiguchi at openjdk.java.net  Wed Oct  6 05:04:28 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 6 Oct 2021 05:04:28 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

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

  8274544: Langtools command's usage were garbled on Japanese Windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5771/files
  - new: https://git.openjdk.java.net/jdk/pull/5771/files/bfe90241..4427d87c

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

  Stats: 61 lines in 8 files changed: 32 ins; 21 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771

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

From itakiguchi at openjdk.java.net  Wed Oct  6 05:09:08 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 6 Oct 2021 05:09:08 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v2]
In-Reply-To: <HWbHjhmiGNwsEJI-pR4nkVlOjdumW3DBgd2ZgZtGQLo=.5ff2abe8-db02-4597-b370-49bad7c80e96@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <TyMEXFLaE9N24VYfH1QkjM-EN5KfW0W5yJqhZoVPk-k=.791ada4a-357d-4d25-8efe-d80bb2c24af5@github.com>
 <HWbHjhmiGNwsEJI-pR4nkVlOjdumW3DBgd2ZgZtGQLo=.5ff2abe8-db02-4597-b370-49bad7c80e96@github.com>
Message-ID: <r6pZcajDONw8HQKehOpahQbmXzfKqiMouVtTitnEuzc=.bb0fe1bd-ea45-4c8d-a584-6479685b5e98@github.com>

On Mon, 4 Oct 2021 16:24:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274544: Langtools command's usage were garbled on Japanese Windows
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 265:
> 
>> 263:      * @return a map of writers
>> 264:      */
>> 265:     private final static Charset nativeCharset;
> 
> Inserting this static initializer in the middle of a method, between its javadoc and impl, is odd.

Moved to another place

> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 267:
> 
>> 265:     private final static Charset nativeCharset;
>> 266:     static {
>> 267:         Charset cs = Charset.defaultCharset();
> 
> This could move into the `catch` section as a last resort.

Move `cs = Charset.defaultCharset()` into `catch` section

> src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java line 419:
> 
>> 417:             return new PrintWriter(System.err, true, nativeCharset);
>> 418:         } else {
>> 419:             if (s.equals((OutputStream)System.err) || s.equals((OutputStream)System.out)) {
> 
> Can we use `==` here?

Used `==`

> src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java line 50:
> 
>> 48:      * @param args command line arguments
>> 49:      */
>> 50:     private final static Charset nativeCharset;
> 
> Static initializer dissecting main method (javadoc/impl)

Moved to another place

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

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

From alanb at openjdk.java.net  Wed Oct  6 06:19:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 6 Oct 2021 06:19:06 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
Message-ID: <7jj8-5dFFwzwOh5Un59vvBrL512C179k9Veai48U0GI=.3d58bf5c-dfee-46c7-bd44-5bfc76ed1805@github.com>

On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274544: Langtools command's usage were garbled on Japanese Windows

The changes in 4427d87c look okay. I assume most of these tools will never run with a SM enabled and don't need to be granted permission to reading native.encoding.

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

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

From serb at openjdk.java.net  Wed Oct  6 06:52:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 6 Oct 2021 06:52:23 GMT
Subject: <i18n dev> RFR: 8274806: Simplify equals() call on nullable
 variable and a constant in java.desktop
In-Reply-To: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
References: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
Message-ID: <DNk_2qGGR0HJUpRUc-_lGDVgCSY2KDmmwI_NhA4ezkg=.8a0bae19-79ed-472a-acee-777c6555d73c@github.com>

On Sat, 2 Oct 2021 09:14:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

Looks fine

src/java.desktop/share/classes/javax/swing/JSplitPane.java line 1000:

> 998:             leftComponent = comp;
> 999:             index = -1;
> 1000:         } else if (JSplitPane.RIGHT.equals(constraints) ||

I do not think that calling the equals on some object is equivalent to calling the equals on String. Please check other cases for similar issues.

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 06:52:22 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 06:52:22 GMT
Subject: <i18n dev> RFR: 8274806: Simplify equals() call on nullable
 variable and a constant in java.desktop
Message-ID: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>

Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

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

Commit messages:
 - [PATCH] Simplify equals() call on nullable variable and a constant in java.desktop
 - [PATCH] Simplify equals() call on nullable variable and a constant

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Oct  6 12:29:23 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 6 Oct 2021 12:29:23 GMT
Subject: <i18n dev> RFR: 8274835: Remove unnecessary castings in java.base
Message-ID: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>

Redundant castings make code harder to read.
Found them by IntelliJ IDEA.
I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

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

Commit messages:
 - [PATCH] Remove unnecessary castings in java.base
 - [PATCH] Remove unnecessary castings in java.base

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

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

From mullan at openjdk.java.net  Wed Oct  6 13:05:07 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 6 Oct 2021 13:05:07 GMT
Subject: <i18n dev> RFR: 8274835: Remove unnecessary castings in
 java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <2g6lp6Qoc6CkGSZxYcxU6J9lyufzUB_nM-JtXOt7Yng=.66528e37-4512-47d6-9818-7acc6a99a42d@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

The security related files look fine.

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

Marked as reviewed by mullan (Reviewer).

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

From itakiguchi at openjdk.java.net  Wed Oct  6 15:58:07 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 6 Oct 2021 15:58:07 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v2]
In-Reply-To: <LRnl9i-pqu67p1ifZGSaJWipAnDh28JrwTeoOeK4r7A=.a5b8157f-3ef3-47b2-8718-361b00261e03@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <TyMEXFLaE9N24VYfH1QkjM-EN5KfW0W5yJqhZoVPk-k=.791ada4a-357d-4d25-8efe-d80bb2c24af5@github.com>
 <LRnl9i-pqu67p1ifZGSaJWipAnDh28JrwTeoOeK4r7A=.a5b8157f-3ef3-47b2-8718-361b00261e03@github.com>
Message-ID: <cJ-d8xi4rY6DntuhoNMYYWImXxYvRP4GuM3pgm36Wbs=.03d65a6f-0db3-4dea-a35e-c8f43e77e1c9@github.com>

On Wed, 6 Oct 2021 00:02:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274544: Langtools command's usage were garbled on Japanese Windows
>
> I just grepped `System.out/err` in jshell source directory, and found another location in `tool/JShellToolProvider.java` that uses bare stdout/err. Would you also apply the fix and see the result?

Hello @naotoj .
Sorry I'm late.
> I just grepped `System.out/err` in jshell source directory, and found another location in `tool/JShellToolProvider.java` that uses bare stdout/err. Would you also apply the fix and see the result?

I applied following changes and lahodaj's code (I'm not sure, it's expected one...)

                         : in;
         PrintStream xout =
                 (out == null)
-                        ? System.out
+                        ? new PrintStream(System.out, true, nativeCharset)
                         : (out instanceof PrintStream)
                                 ? (PrintStream) out
-                                : new PrintStream(out);
+                                : new PrintStream(out, true, nativeCharset);
         PrintStream xerr =
                 (err == null)
-                        ? System.err
+                        ? new PrintStream(System.err, true, nativeCharset)
                         : (err instanceof PrintStream)
                                 ? (PrintStream) err
-                                : new PrintStream(err);
+                                : new PrintStream(err, true, nativeCharset);
         try {
             return JavaShellToolBuilder
                     .builder()


But it did not work for previously saved encoded command list.
(lahodaj's code worked fine for standard case.)

I think you may be confused because of my bad explanation.
User can create Jshell's command list by `/save`.
Native encoding was used before JDK18.
Now UTF-8 is used by JDK18.
To read saved command list (`/open`) which was encoded by native encoding, Charset.defaultCharset() should be same as native.encoding...
I think we need to provide workaround for it.

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

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

From naoto at openjdk.java.net  Wed Oct  6 16:28:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Oct 2021 16:28:06 GMT
Subject: <i18n dev> RFR: 8274835: Remove unnecessary castings in
 java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <bjZ-M-6Z6gJtz-cqjVE5v8-6mkv_3XnoLeU8vuq3U0E=.61ef8c3b-31e6-4ad2-872c-7934502fa8a7@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Calendar-related changes look good to me.

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

Marked as reviewed by naoto (Reviewer).

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

From lancea at openjdk.java.net  Wed Oct  6 16:33:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 6 Oct 2021 16:33:09 GMT
Subject: <i18n dev> RFR: 8274835: Remove unnecessary castings in
 java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <izYxd9rrVsXAmp4ucJKzcuPcA9YMeQ8TcBQSARA-484=.fcfdb84d-518e-44b7-b878-d9a2aa7fe92e@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Marked as reviewed by lancea (Reviewer).

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

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

From darcy at openjdk.java.net  Wed Oct  6 17:15:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 6 Oct 2021 17:15:08 GMT
Subject: <i18n dev> RFR: 8274835: Remove unnecessary castings in
 java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <5cblPwQq4ebGNXXrtO9EoHnSZ_tcsn-EVxfMQMVEjOI=.9936fe80-1b9a-468c-8d3e-80eaad0977be@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

Curious. The JDK build is done with javac -Xlint:cast warning enabled (JDK-8032734) which is intended to catch issues like this. Perhaps IntelliJ is using a different (or sharper) analysis.

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

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

From rriggs at openjdk.java.net  Wed Oct  6 17:26:09 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 6 Oct 2021 17:26:09 GMT
Subject: <i18n dev> RFR: 8274407: (tz) Update Timezone Data to 2021c
In-Reply-To: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
References: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
Message-ID: <uK4TdqbHS_DEXz8EkmMW_yZFdHwNR_LjUFQxeok-cug=.1e2d5090-42f8-462d-aaeb-236ead906143@github.com>

On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted.
> The PR also fixes two issues along with the 2021c upgrade.

Marked as reviewed by rriggs (Reviewer).

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

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

From naoto at openjdk.java.net  Wed Oct  6 18:11:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Oct 2021 18:11:10 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
Message-ID: <s-YDaTSJbMVWWhARpNlYsqZPjjqa12UIhHue6GokMcw=.a0ed8d8c-1861-4ae9-84b3-7b8f21009c76@github.com>

On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274544: Langtools command's usage were garbled on Japanese Windows

I got your issue now. Since the current code issues `FileReader()` without specifying the explicit charset, this is the prime example that is affected by the JEP. The question is, in which encoding the jshell save file should be? I think it belongs to the spec of jshell, and it should be specified somewhere in the document.

BTW, the suggestion I made in `JShellToolProvider` still holds regardless of the save file issue.

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

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

From iris at openjdk.java.net  Wed Oct  6 18:11:12 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 6 Oct 2021 18:11:12 GMT
Subject: <i18n dev> RFR: 8274407: (tz) Update Timezone Data to 2021c
In-Reply-To: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
References: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
Message-ID: <MnWJJ_ubN1qMiblQ8xHUzxnjvVPSpczOVQI45E5CShA=.0c2855ab-ff78-406b-a706-3e61d3a585ec@github.com>

On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted.
> The PR also fixes two issues along with the 2021c upgrade.

Marked as reviewed by iris (Reviewer).

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

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

From coffeys at openjdk.java.net  Wed Oct  6 19:47:05 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Wed, 6 Oct 2021 19:47:05 GMT
Subject: <i18n dev> RFR: 8274407: (tz) Update Timezone Data to 2021c
In-Reply-To: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
References: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
Message-ID: <a-Mzoly_e32Uig5gPXGQ6v9NrOExa0AWiLYkN8IAtT8=.47628a23-1997-4e88-90d4-2c67266ffe3f@github.com>

On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted.
> The PR also fixes two issues along with the 2021c upgrade.

Marked as reviewed by coffeys (Reviewer).

pre-1970 data for some time zones is lost or becomes inaccurate with this tzdata release. Do we plan to release-note that point  ?

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

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

From naoto at openjdk.java.net  Wed Oct  6 19:55:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Oct 2021 19:55:05 GMT
Subject: <i18n dev> RFR: 8274407: (tz) Update Timezone Data to 2021c
In-Reply-To: <a-Mzoly_e32Uig5gPXGQ6v9NrOExa0AWiLYkN8IAtT8=.47628a23-1997-4e88-90d4-2c67266ffe3f@github.com>
References: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
 <a-Mzoly_e32Uig5gPXGQ6v9NrOExa0AWiLYkN8IAtT8=.47628a23-1997-4e88-90d4-2c67266ffe3f@github.com>
Message-ID: <LFYLd_9xX0-5O2XONP8mgKRvAWFmBwMiOj4mQsN3nwY=.b7b0586a-51df-4994-8d94-a02affd93c88@github.com>

On Wed, 6 Oct 2021 19:43:06 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted.
>> The PR also fixes two issues along with the 2021c upgrade.
>
> pre-1970 data for some time zones is lost or becomes inaccurate with this tzdata release. Do we plan to release-note that point  ?

Good point, @coffeys. I'll make sure they are described in the release note.

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

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

From bpb at openjdk.java.net  Wed Oct  6 21:08:12 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 6 Oct 2021 21:08:12 GMT
Subject: <i18n dev> RFR: 8274835: Remove unnecessary castings in
 java.base
In-Reply-To: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
References: <S7WTTAMl1exfs5H8ODSOHUdEX0abEKOkEz4kRIlhiU4=.c39014f7-030b-4360-a8e5-4ceb01f8921f@github.com>
Message-ID: <wee37TyGNDjU0xrCVV9iO2UWHgZtVwT22jL8ZQTTJpI=.7ecb2791-480e-4b2b-b155-c826bcd7d161@github.com>

On Thu, 9 Sep 2021 20:12:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Redundant castings make code harder to read.
> Found them by IntelliJ IDEA.
> I tried to select only casts which are definitely safe to remove. Also didn't touch primitive types casts.

`java.io` change looks all right.

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

Marked as reviewed by bpb (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 07:35:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 07:35:21 GMT
Subject: <i18n dev> RFR: 8274879: Replace uses of StringBuffer with
 StringBuilder within java.base classes
Message-ID: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>

StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
1. Plain String concatenation should be preferred
2. StringBuilder is a direct replacement to StringBuffer which generally have better performance

In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

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

Commit messages:
 - [PATCH] Cleanup usages of StringBuffer in java.base module
 - [PATCH] Cleanup usages of StringBuffer in java.base module

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

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

From serb at openjdk.java.net  Thu Oct  7 09:03:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Oct 2021 09:03:07 GMT
Subject: <i18n dev> RFR: 8274806: Simplify equals() call on nullable
 variable and a constant in java.desktop
In-Reply-To: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
References: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
Message-ID: <uJwYxt3HrHwF2EfW0obfA9L7NFE_tyhMvhtpxzQF2Cw=.7f2ebad2-fdab-451b-94ec-568149a359df@github.com>

On Sat, 2 Oct 2021 09:14:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

Marked as reviewed by serb (Reviewer).

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

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

From pbansal at openjdk.java.net  Thu Oct  7 09:11:12 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 7 Oct 2021 09:11:12 GMT
Subject: <i18n dev> RFR: 8274806: Simplify equals() call on nullable
 variable and a constant in java.desktop
In-Reply-To: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
References: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
Message-ID: <aHJQud28sKjC-O_FC6_WKvzcmgV1YMNQFsVIbb8Vh84=.69234042-ecc6-4c8e-9cd1-74e872d5c2a4@github.com>

On Sat, 2 Oct 2021 09:14:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

looks good to me

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

Marked as reviewed by pbansal (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Oct  7 10:23:28 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 7 Oct 2021 10:23:28 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources
Message-ID: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>

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

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

Commit messages:
 - [PATCH] Use try-with-resources to close resources in java.desktop
 - [PATCH] Use try-with-resources to close resources in java.desktop
 - [PATCH] Use try-with-resources to close InputStream in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/5817/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5817&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274893
  Stats: 217 lines in 24 files changed: 20 ins; 105 del; 92 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5817/head:pull/5817

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

From naoto at openjdk.java.net  Thu Oct  7 15:35:15 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Oct 2021 15:35:15 GMT
Subject: <i18n dev> Integrated: 8274407: (tz) Update Timezone Data to 2021c
In-Reply-To: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
References: <x-sED8LZVKVZDd8yNA24rmzvneayYTmi3IWQDvqisDo=.095a4b56-a4e2-43c9-a2cc-dc1e9f830511@github.com>
Message-ID: <_NX0H0er1wkmnT5nKFEBD8ChF26s46LrDsEgIn0A5VU=.bd4ba204-8052-4545-8e97-1b1e6fd8881b@github.com>

On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c level. Note that the tz data is "as is", as released by IANA. No `merged links` are retracted.
> The PR also fixes two issues along with the 2021c upgrade.

This pull request has now been integrated.

Changeset: 8ca08461
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8ca084617f331b6af934179f3f776c8158da5bba
Stats:     635 lines in 13 files changed: 228 ins; 329 del; 78 mod

8274407: (tz) Update Timezone Data to 2021c
8274467: TestZoneInfo310.java fails with tzdata2021b
8274468: TimeZoneTest.java fails with tzdata2021b

Reviewed-by: rriggs, iris, coffeys

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

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

From naoto at openjdk.java.net  Thu Oct  7 16:52:13 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Oct 2021 16:52:13 GMT
Subject: <i18n dev> RFR: 8274879: Replace uses of StringBuffer with
 StringBuilder within java.base classes
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>

On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

src/java.base/share/classes/java/lang/Character.java line 123:

> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
> 123:  * in the {@code String} and {@code StringBuilder} classes. In

Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.

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

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

From naoto at openjdk.java.net  Thu Oct  7 21:36:21 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 7 Oct 2021 21:36:21 GMT
Subject: <i18n dev> RFR: 8274864: Remove Amman/Cairo hacks in ZoneInfoFile
Message-ID: <hL2r9jBT9FBB7J__0MwhdP7N5Gtn_-enlWWMA3phE5g=.5b0fe379-b7ef-4474-977c-c78a9595ccd9@github.com>

While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day.

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

Commit messages:
 - 8274864: Remove Amman/Cairo hacks in ZoneInfoFile

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

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

From iris at openjdk.java.net  Thu Oct  7 23:13:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 7 Oct 2021 23:13:06 GMT
Subject: <i18n dev> RFR: 8274864: Remove Amman/Cairo hacks in
 ZoneInfoFile
In-Reply-To: <hL2r9jBT9FBB7J__0MwhdP7N5Gtn_-enlWWMA3phE5g=.5b0fe379-b7ef-4474-977c-c78a9595ccd9@github.com>
References: <hL2r9jBT9FBB7J__0MwhdP7N5Gtn_-enlWWMA3phE5g=.5b0fe379-b7ef-4474-977c-c78a9595ccd9@github.com>
Message-ID: <ekxdWR4kNBRsvRSFek5AfqtDXL7nWa9jvLpmjl-X1c4=.db14b876-b6d5-4445-af38-64f60f89da78@github.com>

On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day.

Marked as reviewed by iris (Reviewer).

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

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

From serb at openjdk.java.net  Fri Oct  8 00:19:05 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 00:19:05 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <EbfOB5mmFL1ZgltetdXtwRmaRAWRuX7DwA8Ht0HkNyU=.19467570-ac50-4548-aa60-1755a3c44768@github.com>

On Mon, 4 Oct 2021 14:54:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

I am fine with any solution but think the check will be simpler and safer, and later we will be able to change the behavior of some of these methods if it will be needed.

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

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

From joehw at openjdk.java.net  Fri Oct  8 07:12:07 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 8 Oct 2021 07:12:07 GMT
Subject: <i18n dev> RFR: 8274864: Remove Amman/Cairo hacks in
 ZoneInfoFile
In-Reply-To: <hL2r9jBT9FBB7J__0MwhdP7N5Gtn_-enlWWMA3phE5g=.5b0fe379-b7ef-4474-977c-c78a9595ccd9@github.com>
References: <hL2r9jBT9FBB7J__0MwhdP7N5Gtn_-enlWWMA3phE5g=.5b0fe379-b7ef-4474-977c-c78a9595ccd9@github.com>
Message-ID: <MBHPxi7IK2dyT3hWI1sq9kAErXvhtqxwxZXpAvJDHHo=.f2de6db1-28cd-4a08-ab95-45983647556f@github.com>

On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day.

Marked as reviewed by joehw (Reviewer).

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

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

From weijun at openjdk.java.net  Fri Oct  8 07:29:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 8 Oct 2021 07:29:27 GMT
Subject: <i18n dev> RFR: 8274949: Use String.contains() instead of
 String.indexOf() in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <2wrfMoUmLw_xar7QqdTGlx3lRRn5ezXWZI3F6MIJoVo=.9e0d608d-6cf2-47ad-ae11-134f5d77bffe@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

security-related change looks fine.

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

Marked as reviewed by weijun (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  8 07:29:27 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 8 Oct 2021 07:29:27 GMT
Subject: <i18n dev> RFR: 8274949: Use String.contains() instead of
 String.indexOf() in java.base
Message-ID: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>

String.contains was introduced in Java 5.
Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
I propose to migrate such usages. Makes code shorter and easier to read.

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

Commit messages:
 - [PATCH] Use String.contains() instead of String.indexOf() in java.base
 - [PATCH] Use String.contains() instead of String.indexOf() in java.base

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

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

From jdv at openjdk.java.net  Fri Oct  8 07:41:19 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Fri, 8 Oct 2021 07:41:19 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v3]
In-Reply-To: <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>
Message-ID: <VFpOcB6a0dzCLy42Lj18VYKGpSDa9ll7E1T4fx6g6V8=.d9205ccb-0d7e-498f-9b02-6cfd1a57cd70@github.com>

On Sat, 25 Sep 2021 19:30:31 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 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

Marked as reviewed by jdv (Reviewer).

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

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

From dfuchs at openjdk.java.net  Fri Oct  8 09:38:04 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 8 Oct 2021 09:38:04 GMT
Subject: <i18n dev> RFR: 8274949: Use String.contains() instead of
 String.indexOf() in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Changes to java.net look OK. Did you run tier1, tier2?

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

Marked as reviewed by dfuchs (Reviewer).

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

From vtewari at openjdk.java.net  Fri Oct  8 10:15:07 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 8 Oct 2021 10:15:07 GMT
Subject: <i18n dev> RFR: 8274949: Use String.contains() instead of
 String.indexOf() in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <IK_jmGQWQ0HohqSRE-kTgY-Xcjab4WNHUbkO3ITkDp4=.2c7d07c2-150b-4752-a429-f81da53621cb@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

java.net changes look OK to me.

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

Marked as reviewed by vtewari (Committer).

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

From lancea at openjdk.java.net  Fri Oct  8 10:20:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 8 Oct 2021 10:20:09 GMT
Subject: <i18n dev> RFR: 8274949: Use String.contains() instead of
 String.indexOf() in java.base
In-Reply-To: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
Message-ID: <w0KXXui1E0dtoghdpDHBut8BcBEesJdxM8-0O-DvEB4=.0ff06e02-50e2-4eb8-baa3-53d80db03e27@github.com>

On Fri, 17 Sep 2021 08:56:47 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> String.contains was introduced in Java 5.
> Some code in java.base still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Marked as reviewed by lancea (Reviewer).

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

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Oct  8 14:01:10 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 8 Oct 2021 14:01:10 GMT
Subject: <i18n dev> RFR: 8274949: Use String.contains() instead of
 String.indexOf() in java.base
In-Reply-To: <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>
References: <bspVa-SvvajDvRpzQTUlBG1nODmRBb4GdZfdcsLJXOQ=.0b63c356-20cd-4318-a087-f83959020ee5@github.com>
 <2MqVsvFTfYzzjenWPASS0ZB0lzHlnwF3GJ7K8lOqpP0=.db5edd8a-b93e-46b4-a33d-4fe63a96caef@github.com>
Message-ID: <w_TDnyfEJSM2qLXD2W0TGC5jlTDA1UFo3fyR2gySq5U=.b26a16ce-69f8-44b7-b1d8-069fd7c1ce31@github.com>

On Fri, 8 Oct 2021 09:35:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>Did you run tier1, tier2?

I did run tier2. (tier1 is automatically checked by GithubActions).
No new tests failed. Only _usual_ tests, which always fail on my machine, were failed.

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

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

From aivanov at openjdk.java.net  Fri Oct  8 15:33:14 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Oct 2021 15:33:14 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v3]
In-Reply-To: <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>
References: <OZRejHqXN3I_i4h8TnElUdeNgsq0OMMikn04q9nXPw8=.918a4c1a-9b00-4f34-a296-3d21e1fcc3ac@github.com>
 <HTEWllQGW95dAuz2LclbAaQ8DJrmzjUwJVSAem3GFh4=.e0f6cac2-07b0-43df-8d0a-c99b07434530@github.com>
Message-ID: <V_VGqFcYAVr-15-Qwr8sUNUDjwJSPWV9f442MsUTLec=.e31a0eeb-8dc3-468f-ae66-a773161b8fab@github.com>

On Sat, 25 Sep 2021 19:30:31 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 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

Marked as reviewed by aivanov (Reviewer).

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Fri Oct  8 16:04:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 8 Oct 2021 16:04:11 GMT
Subject: <i18n dev> Integrated: 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: <OHNnhxXi8nN1NfL14aXHwo37nVvPTXHhjPM3TRUTJmE=.a257f8f0-fade-452d-961d-a90dec733f3a@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._

This pull request has now been integrated.

Changeset: ccbce107
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ccbce107f299c3b1c444e819c1fda7ae3c4866b5
Stats:     54 lines in 28 files changed: 0 ins; 0 del; 54 mod

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

Reviewed-by: jdv, aivanov

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

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

From naoto at openjdk.java.net  Fri Oct  8 16:14:15 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Oct 2021 16:14:15 GMT
Subject: <i18n dev> Integrated: 8274864: Remove Amman/Cairo hacks in
 ZoneInfoFile
In-Reply-To: <hL2r9jBT9FBB7J__0MwhdP7N5Gtn_-enlWWMA3phE5g=.5b0fe379-b7ef-4474-977c-c78a9595ccd9@github.com>
References: <hL2r9jBT9FBB7J__0MwhdP7N5Gtn_-enlWWMA3phE5g=.5b0fe379-b7ef-4474-977c-c78a9595ccd9@github.com>
Message-ID: <RBRjnpjJV3nqJJbTuXPgDl3h7cJs1ZFjD5XJXiA_VZc=.b1d9fc6f-426f-4861-9ee2-7dc2439e5858@github.com>

On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day.

This pull request has now been integrated.

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

8274864: Remove Amman/Cairo hacks in ZoneInfoFile

Reviewed-by: iris, joehw

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

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

From itakiguchi at openjdk.java.net  Fri Oct  8 17:44:12 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 8 Oct 2021 17:44:12 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <s-YDaTSJbMVWWhARpNlYsqZPjjqa12UIhHue6GokMcw=.a0ed8d8c-1861-4ae9-84b3-7b8f21009c76@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
 <s-YDaTSJbMVWWhARpNlYsqZPjjqa12UIhHue6GokMcw=.a0ed8d8c-1861-4ae9-84b3-7b8f21009c76@github.com>
Message-ID: <UHhlcp22WUp7Xo4iEpPWqjvtz-NNuw1Kf0h_y6fhfyQ=.3da3bb63-27b2-4170-a392-112b121b959e@github.com>

On Wed, 6 Oct 2021 18:08:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274544: Langtools command's usage were garbled on Japanese Windows
>
> I got your issue now. Since the current code issues `FileReader()` without specifying the explicit charset, this is the prime example that is affected by the JEP. The question is, in which encoding the jshell save file should be? I think it belongs to the spec of jshell, and it should be specified somewhere in the document.
> 
> BTW, the suggestion I made in `JShellToolProvider` still holds regardless of the save file issue.

Hello @naotoj .
Do you think I need to fix jshell issue by this PR ?

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

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

From naoto at openjdk.java.net  Fri Oct  8 18:17:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Oct 2021 18:17:10 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <s-YDaTSJbMVWWhARpNlYsqZPjjqa12UIhHue6GokMcw=.a0ed8d8c-1861-4ae9-84b3-7b8f21009c76@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
 <s-YDaTSJbMVWWhARpNlYsqZPjjqa12UIhHue6GokMcw=.a0ed8d8c-1861-4ae9-84b3-7b8f21009c76@github.com>
Message-ID: <ngv6JUkGHDooo3Fpz8wFcgkHeucropYrvBpJO4Viv1E=.5ef758d5-a6db-4eea-8600-3a4de04e26f0@github.com>

On Wed, 6 Oct 2021 18:08:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274544: Langtools command's usage were garbled on Japanese Windows
>
> I got your issue now. Since the current code issues `FileReader()` without specifying the explicit charset, this is the prime example that is affected by the JEP. The question is, in which encoding the jshell save file should be? I think it belongs to the spec of jshell, and it should be specified somewhere in the document.
> 
> BTW, the suggestion I made in `JShellToolProvider` still holds regardless of the save file issue.

> Hello @naotoj . Do you think I need to fix jshell issue by this PR ?

I'd appreciate it, as I don't have a Japanese Windows environment at hand.

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

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

From serb at openjdk.java.net  Fri Oct  8 18:39:12 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 18:39:12 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v3]
In-Reply-To: <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@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>
 <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
Message-ID: <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>

On Sun, 26 Sep 2021 20:57:58 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Agree.
>
> I still suggest to remove the local tag completely.

@jayathirthrao @stsypanov  Looks like this was not addressed?  It will be good to include it in some future cleanup.

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

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

From aivanov at openjdk.java.net  Fri Oct  8 18:50:12 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Oct 2021 18:50:12 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v3]
In-Reply-To: <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@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>
 <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
 <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>
Message-ID: <m8Ld3F0yc15DfH7wheZmF_UwhlA-AYEoUlK2om3VslE=.7e7667a9-d23f-4d2d-9866-bdc2b70a9d9a@github.com>

On Fri, 8 Oct 2021 18:35:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I still suggest to remove the local tag completely.
>
> @jayathirthrao @stsypanov  Looks like this was not addressed?  It will be good to include it in some future cleanup.

As far as I can see, it was. [Line 64](https://github.com/stsypanov/jdk/blob/d13ca9004b8e45f7df57c849271f3cfda5c43ec9/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java#L64):

            essentialTags = Set.of(


And it shows as such in [the diff of the commit](https://github.com/openjdk/jdk/commit/ccbce107f299c3b1c444e819c1fda7ae3c4866b5#diff-054fa06ac6a28817c38d879245a8490f22789d7c93d51b723c08616e154746c9).

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

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

From serb at openjdk.java.net  Fri Oct  8 19:19:09 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 8 Oct 2021 19:19:09 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v3]
In-Reply-To: <m8Ld3F0yc15DfH7wheZmF_UwhlA-AYEoUlK2om3VslE=.7e7667a9-d23f-4d2d-9866-bdc2b70a9d9a@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>
 <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
 <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>
 <m8Ld3F0yc15DfH7wheZmF_UwhlA-AYEoUlK2om3VslE=.7e7667a9-d23f-4d2d-9866-bdc2b70a9d9a@github.com>
Message-ID: <DpKpLN_GnVBgAEXzGxYPIkV99DoL69P0lt6g4dT00aY=.4f65db56-c665-46ec-a566-c604cef46e2f@github.com>

On Fri, 8 Oct 2021 18:44:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @jayathirthrao @stsypanov  Looks like this was not addressed?  It will be good to include it in some future cleanup.
>
> As far as I can see, it was. [Line 64](https://github.com/stsypanov/jdk/blob/d13ca9004b8e45f7df57c849271f3cfda5c43ec9/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java#L64):
> 
>             essentialTags = Set.of(
> 
> 
> And it shows as such in [the diff of the commit](https://github.com/openjdk/jdk/commit/ccbce107f299c3b1c444e819c1fda7ae3c4866b5#diff-054fa06ac6a28817c38d879245a8490f22789d7c93d51b723c08616e154746c9).

That was the usage of the local var, the current thread was about the local var itself, it is still there.

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

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

From aivanov at openjdk.java.net  Fri Oct  8 19:23:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 8 Oct 2021 19:23:13 GMT
Subject: <i18n dev> RFR: 8272756: Remove unnecessary explicit
 initialization of volatile variables in java.desktop [v3]
In-Reply-To: <DpKpLN_GnVBgAEXzGxYPIkV99DoL69P0lt6g4dT00aY=.4f65db56-c665-46ec-a566-c604cef46e2f@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>
 <gnl7URRoEcqD7Dnb2-LkT6wucR7OH1eHY5ICtupHuoM=.56c7a040-fb9b-403e-ba3c-aeb83e847d4a@github.com>
 <B8NjgmYChCnd0bMEQtUU9bgbiTMFhnAKfCNuG2KjKsI=.d52f9e1d-ccdc-4385-b20f-bf8549b62102@github.com>
 <m8Ld3F0yc15DfH7wheZmF_UwhlA-AYEoUlK2om3VslE=.7e7667a9-d23f-4d2d-9866-bdc2b70a9d9a@github.com>
 <DpKpLN_GnVBgAEXzGxYPIkV99DoL69P0lt6g4dT00aY=.4f65db56-c665-46ec-a566-c604cef46e2f@github.com>
Message-ID: <2v7DaFfR7eyYtloWn6AnUerhe6bwgneHMPiSc2NFRwI=.57d7bad5-78ae-44db-afcc-0e65786b52cc@github.com>

On Fri, 8 Oct 2021 19:15:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> As far as I can see, it was. [Line 64](https://github.com/stsypanov/jdk/blob/d13ca9004b8e45f7df57c849271f3cfda5c43ec9/src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFIFD.java#L64):
>> 
>>             essentialTags = Set.of(
>> 
>> 
>> And it shows as such in [the diff of the commit](https://github.com/openjdk/jdk/commit/ccbce107f299c3b1c444e819c1fda7ae3c4866b5#diff-054fa06ac6a28817c38d879245a8490f22789d7c93d51b723c08616e154746c9).
>
> That was the usage of the local var, the current thread was about the local var itself, it is still there.

Good catch!
I missed that the local variable is still there and now it's unused, so an IDE should issue a warning about it.

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

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

From naoto at openjdk.java.net  Fri Oct  8 21:10:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 8 Oct 2021 21:10:10 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
Message-ID: <K5os_X9ZHkyVFMGcF78gh5LEnJVFK0N3aOlyChRR3vM=.6f283f2d-dc8b-4c4c-ae7b-bf0d40d9dc80@github.com>

On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274544: Langtools command's usage were garbled on Japanese Windows

BTW, does the PoC in the jshell bug report really causing the issue?

System.out.println("\u3042")

This is ASCII, so save/resotre does not seem to cause any issues across JDKs with and without JEP400. Did you mean `Systemout.println("?")` instead?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sat Oct  9 00:49:11 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 9 Oct 2021 00:49:11 GMT
Subject: <i18n dev> Integrated: 8274806: Simplify equals() call on nullable
 variable and a constant in java.desktop
In-Reply-To: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
References: <aozsDbphQVFrIKPiFaeKV8mtxh4Ay0qIUvpSHn3GgzY=.4c585ab2-10f1-4257-ab2e-dad2ca0c24c5@github.com>
Message-ID: <xC3oYKIv5AdzbiIwvvSWHwe3Q-eS7ErtOE2OAGtFLf0=.788e3a6e-d3bb-4b05-9cd3-d7f0223fd233@github.com>

On Sat, 2 Oct 2021 09:14:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Flipping arguments of 'equals' method, allows simplifying boolean expressions: now we can remove redundant null check before.

This pull request has now been integrated.

Changeset: f640c7aa
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f640c7aaa852b6c0e9144654b7222a6777201370
Stats:     17 lines in 11 files changed: 0 ins; 1 del; 16 mod

8274806: Simplify equals() call on nullable variable and a constant in java.desktop

Reviewed-by: serb, pbansal

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

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

From wuyan at openjdk.java.net  Sat Oct  9 09:09:10 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Sat, 9 Oct 2021 09:09:10 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: <EzYdLoUXV1PF46WWcsgeLoFy2E88Y8-s7I0GLRJxqfo=.f36a8bfb-e3d7-4e76-bce4-35dd893c9861@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <EzYdLoUXV1PF46WWcsgeLoFy2E88Y8-s7I0GLRJxqfo=.f36a8bfb-e3d7-4e76-bce4-35dd893c9861@github.com>
Message-ID: <9ve0dyB1yKCM7BZAF5kUtK2hY2qlLXtdY5AxsSPLzEc=.14a7411a-6408-41f7-aee3-dabe776c247a@github.com>

On Wed, 1 Sep 2021 13:39:46 GMT, Naoto Sato <naoto 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.

Hi, @naotoj, Could you do me a favor to review the patch?

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

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

From azvegint at openjdk.java.net  Sat Oct  9 11:16:29 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 9 Oct 2021 11:16:29 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v2]
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <3ImBG1zONPFt9j_xXbC2ha49uVBoqTZwfUBXP_TQCLI=.91448fe7-a57f-4600-8c7f-ce32c08e42d1@github.com>

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

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

  throw exceptions instead of doc change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5806/files
  - new: https://git.openjdk.java.net/jdk/pull/5806/files/9bf48ed6..6f6f2680

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

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

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

From azvegint at openjdk.java.net  Sat Oct  9 12:02:07 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Sat, 9 Oct 2021 12:02:07 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <EbfOB5mmFL1ZgltetdXtwRmaRAWRuX7DwA8Ht0HkNyU=.19467570-ac50-4548-aa60-1755a3c44768@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <EbfOB5mmFL1ZgltetdXtwRmaRAWRuX7DwA8Ht0HkNyU=.19467570-ac50-4548-aa60-1755a3c44768@github.com>
Message-ID: <zKbRas8EklJKWdoSQiXw_uKTgih6M6U-_x8mAmB2Ftk=.7a32d45b-c6c8-4ccc-84cf-5deda5ec056f@github.com>

On Fri, 8 Oct 2021 00:16:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I am fine with any solution but think the check will be simpler and safer, and later we will be able to change the behavior of some of these methods if it will be needed.

Makes sense. Testing is green with last code changes.
CSR label will be removed once we agreed on this.

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

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

From naoto at openjdk.java.net  Mon Oct 11 18:31:56 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 11 Oct 2021 18:31:56 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: <P328VysApETX_qWBMDHzX4f2zjxoxoZAtVBpl7NZ8Sc=.bcdcdfb1-43a3-4b18-b698-3f3cb0c6f1a5@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

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

> 111:     }
> 112: }
> 113: 

There are a few `*(right + 1)` references in the loops. Is there any possibility that it would run over the buffer?

src/java.base/unix/native/libjava/path_util.h line 31:

> 29: int collapsible(char *names);
> 30: void splitNames(char *names, char **ix);
> 31: void joinNames(char *names, int nc, char **ix);

Are these functions, `collapsible`, `splitNames` and `joinNames` have to be non-static?

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

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

From duke at openjdk.java.net  Mon Oct 11 21:08:49 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 11 Oct 2021 21:08:49 GMT
Subject: <i18n dev> RFR: 8274879: Replace uses of StringBuffer with
 StringBuilder within java.base classes
In-Reply-To: <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
Message-ID: <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>

On Thu, 7 Oct 2021 16:48:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
>> 
>> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.
>
> src/java.base/share/classes/java/lang/Character.java line 123:
> 
>> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
>> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
>> 123:  * in the {@code String} and {@code StringBuilder} classes. In
> 
> Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.

reverted changes in this spec.

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

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

From serb at openjdk.java.net  Tue Oct 12 06:10:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 06:10:54 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v2]
In-Reply-To: <3ImBG1zONPFt9j_xXbC2ha49uVBoqTZwfUBXP_TQCLI=.91448fe7-a57f-4600-8c7f-ce32c08e42d1@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <3ImBG1zONPFt9j_xXbC2ha49uVBoqTZwfUBXP_TQCLI=.91448fe7-a57f-4600-8c7f-ce32c08e42d1@github.com>
Message-ID: <EyKjrAxYxRk5xQsVmY_DrnNwXGZuquhK2nqvyj4-axk=.8425588c-8dca-4937-83ec-194932b04a01@github.com>

On Sat, 9 Oct 2021 11:16:29 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   throw exceptions instead of doc change

src/java.desktop/share/classes/java/awt/im/InputContext.java line 147:

> 145:         // real implementation is in sun.awt.im.InputContext
> 146:         if (locale == null) {
> 147:             throw new NullPointerException();

Probably we can reuse the Objects.requireNonNull()?

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

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

From serb at openjdk.java.net  Tue Oct 12 06:18:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 06:18:51 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <ZuG9q2jWpcnH2eqlcc7QsHdJWz9-xOx_KkPRBb73JrE=.08ad0963-ff8b-4cac-8df2-7ace734d088e@github.com>

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

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

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 587:

> 585:                     // Pending: verify character encoding spec for gconf
> 586:                     StringBuilder sb = new StringBuilder();
> 587:                     try (Reader reader = new InputStreamReader(url.openStream(), ISO_8859_1)) {

I did not check all code but look like in some places the close method was missed when a few streams were wrapped.
Looks like in this place, the "url.openStream()" may be leaked if the constructor of InputStreamReader will throw an exception. Please check other places for similar issues.

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

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

From duke at openjdk.java.net  Tue Oct 12 08:08:00 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 08:08:00 GMT
Subject: <i18n dev> RFR: 8275106: Cleanup Iterator usages in java.desktop
Message-ID: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>

Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
We can use enhanced-for or Collection.removeIf

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

Commit messages:
 - [PATCH] Cleanup Iterator usages in java.desktop
 - [PATCH] Cleanup Iterator usages in java.desktop

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

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

From serb at openjdk.java.net  Tue Oct 12 08:08:01 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 08:08:01 GMT
Subject: <i18n dev> RFR: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
Message-ID: <67_gtYOB0J6rTskYAfPpmfV2vIcVFSaz1E7s1m9fBVo=.378b27d8-5d07-44bb-bd6c-c5a6817eef8a@github.com>

On Fri, 8 Oct 2021 19:37:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
> We can use enhanced-for or Collection.removeIf

src/java.desktop/share/classes/javax/swing/JDesktopPane.java line 330:

> 328:     public JInternalFrame[] getAllFramesInLayer(int layer) {
> 329:         Collection<JInternalFrame> allFrames = getAllFrames(this);
> 330:         allFrames.removeIf(jInternalFrame -> jInternalFrame.getLayer() != layer);

This line is longer than 80 char, you can rename jInternalFrame to the frame.

src/java.desktop/unix/classes/sun/awt/X11/ListHelper.java line 569:

> 567: 
> 568:     private boolean isItemSelected(int index) {
> 569:         for (Integer val : selected) {

In some other places you did unboxing for the loop var, why not in this place?

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

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

From duke at openjdk.java.net  Tue Oct 12 08:08:02 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 08:08:02 GMT
Subject: <i18n dev> RFR: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <67_gtYOB0J6rTskYAfPpmfV2vIcVFSaz1E7s1m9fBVo=.378b27d8-5d07-44bb-bd6c-c5a6817eef8a@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
 <67_gtYOB0J6rTskYAfPpmfV2vIcVFSaz1E7s1m9fBVo=.378b27d8-5d07-44bb-bd6c-c5a6817eef8a@github.com>
Message-ID: <Pk_mgT2Ft7xGG_RCD6ydLXhzYh7QzQz1Y_0hljV5p3k=.380f06f3-6f18-46c9-ba14-81103172ab2d@github.com>

On Tue, 12 Oct 2021 05:49:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
>> We can use enhanced-for or Collection.removeIf
>
> src/java.desktop/unix/classes/sun/awt/X11/ListHelper.java line 569:
> 
>> 567: 
>> 568:     private boolean isItemSelected(int index) {
>> 569:         for (Integer val : selected) {
> 
> In some other places you did unboxing for the loop var, why not in this place?

I tried to mimic original code.
If in original code iterator.next() was assigned to a primitive - I use primitive for loop variable declaration.

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

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

From azvegint at openjdk.java.net  Tue Oct 12 13:39:21 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 12 Oct 2021 13:39:21 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v3]
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <YyttCdiq2pvjMGLSlX_cGFyHh1O2RGS4NN_ZN_vJXaA=.a97df6a7-c789-4f28-921e-e9d5d4eac0b3@github.com>

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

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

  use Objects.requireNonNull

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5806/files
  - new: https://git.openjdk.java.net/jdk/pull/5806/files/6f6f2680..7ee18860

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

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

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

From azvegint at openjdk.java.net  Tue Oct 12 13:39:26 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Tue, 12 Oct 2021 13:39:26 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v2]
In-Reply-To: <EyKjrAxYxRk5xQsVmY_DrnNwXGZuquhK2nqvyj4-axk=.8425588c-8dca-4937-83ec-194932b04a01@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <3ImBG1zONPFt9j_xXbC2ha49uVBoqTZwfUBXP_TQCLI=.91448fe7-a57f-4600-8c7f-ce32c08e42d1@github.com>
 <EyKjrAxYxRk5xQsVmY_DrnNwXGZuquhK2nqvyj4-axk=.8425588c-8dca-4937-83ec-194932b04a01@github.com>
Message-ID: <2CqX5Mv_7AtpidKqXK-Uxi0qLx83BF8b7Q041ncuGO0=.789c14e5-43f1-486e-b3cf-d149a66a98f4@github.com>

On Tue, 12 Oct 2021 06:07:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   throw exceptions instead of doc change
>
> src/java.desktop/share/classes/java/awt/im/InputContext.java line 147:
> 
>> 145:         // real implementation is in sun.awt.im.InputContext
>> 146:         if (locale == null) {
>> 147:             throw new NullPointerException();
> 
> Probably we can reuse the Objects.requireNonNull()?

Sure.

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

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

From serb at openjdk.java.net  Tue Oct 12 19:52:49 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 19:52:49 GMT
Subject: <i18n dev> RFR: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing [v3]
In-Reply-To: <YyttCdiq2pvjMGLSlX_cGFyHh1O2RGS4NN_ZN_vJXaA=.a97df6a7-c789-4f28-921e-e9d5d4eac0b3@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
 <YyttCdiq2pvjMGLSlX_cGFyHh1O2RGS4NN_ZN_vJXaA=.a97df6a7-c789-4f28-921e-e9d5d4eac0b3@github.com>
Message-ID: <6o57ovUp6BbtHXnpabSsUPyQ02rqgQkRgScwj7Wymmc=.18fec80e-a529-4f38-a31f-0302a4a31457@github.com>

On Tue, 12 Oct 2021 13:39:21 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Objects.requireNonNull

Marked as reviewed by serb (Reviewer).

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

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

From naoto at openjdk.java.net  Tue Oct 12 20:39:14 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Oct 2021 20:39:14 GMT
Subject: <i18n dev> RFR: 8274879: Replace uses of StringBuffer with
 StringBuilder within java.base classes [v2]
In-Reply-To: <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
 <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
Message-ID: <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>

On Mon, 11 Oct 2021 21:05:46 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/Character.java line 123:
>> 
>>> 121:  * than U+FFFF are called <em>supplementary character</em>s.  The Java
>>> 122:  * platform uses the UTF-16 representation in {@code char} arrays and
>>> 123:  * in the {@code String} and {@code StringBuilder} classes. In
>> 
>> Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16` representation. You may add `StringBuilder` as well here, but I think you might want to file a CSR to clarify.
>
> reverted changes in this spec.

Did you modify the PR? I am unable to locate the revert.

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

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

From duke at openjdk.java.net  Tue Oct 12 20:39:13 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 20:39:13 GMT
Subject: <i18n dev> RFR: 8274879: Replace uses of StringBuffer with
 StringBuilder within java.base classes [v2]
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

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

  8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
  revert changes in spec to avoid CSR

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5432/files
  - new: https://git.openjdk.java.net/jdk/pull/5432/files/14005d1d..c8d68c2a

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

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

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

From duke at openjdk.java.net  Tue Oct 12 20:39:14 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 12 Oct 2021 20:39:14 GMT
Subject: <i18n dev> RFR: 8274879: Replace uses of StringBuffer with
 StringBuilder within java.base classes [v2]
In-Reply-To: <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <hiaSBKv6xl7HFHRDSB8w97ZSvjV-z73KtI_iAvvrcXY=.fade4d41-6d8f-44e6-9510-c40c128c86e4@github.com>
 <BC2mHqy5mDyRFKjO3GXZnYPgWGXbhaqPnnh27yPsYSg=.163919a1-6291-407b-a1a7-3bdee20a25f3@github.com>
 <XMhmq2JMHqblQIUMol2ZDFLuMJ-kCfl_T36n9BjQskI=.26563814-2916-4724-b2d4-251a039a6260@github.com>
Message-ID: <J1wtQXATnYkW26m1PpnmlmQyjMgzGRdP4OtATWagep0=.796bb462-c2c3-4bcb-ad4c-a0525681f470@github.com>

On Tue, 12 Oct 2021 20:33:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> reverted changes in this spec.
>
> Did you modify the PR? I am unable to locate the revert.

Oops. Forgot to push

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

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

From serb at openjdk.java.net  Tue Oct 12 20:44:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 12 Oct 2021 20:44:48 GMT
Subject: <i18n dev> RFR: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
Message-ID: <YbuIr7y-I2hIolooSlo5ohM5xGxiOv0FRUC9doPyo5c=.9fac69a3-90d6-48e4-ab20-f724bdef9d33@github.com>

On Fri, 8 Oct 2021 19:37:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
> We can use enhanced-for or Collection.removeIf

Marked as reviewed by serb (Reviewer).

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

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

From naoto at openjdk.java.net  Tue Oct 12 20:46:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 12 Oct 2021 20:46:50 GMT
Subject: <i18n dev> RFR: 8274879: Replace uses of StringBuffer with
 StringBuilder within java.base classes [v2]
In-Reply-To: <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
 <e2TZN9ufjX6T7z7ENtkJSqbc4zxrWcIKgUjWHl0pMlc=.fdc6e55b-6d9a-4f76-aa58-b1185176535a@github.com>
Message-ID: <R-tgDRJ5SKkQATM35Q4ApUdtppXYZQqEw0vhC96tvuM=.907d5018-af76-4a7d-add7-d79238d30741@github.com>

On Tue, 12 Oct 2021 20:39:13 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
>> 
>> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
>   revert changes in spec to avoid CSR

Marked as reviewed by naoto (Reviewer).

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

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

From duke at openjdk.java.net  Wed Oct 13 07:28:07 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 13 Oct 2021 07:28:07 GMT
Subject: <i18n dev> RFR: 8275197: Remove unused fields in
 ThaiBuddhistChronology
Message-ID: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>

Remove 3 unused HashMap's.
Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html
I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155

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

Commit messages:
 - [PATCH] Remove unused fields in ThaiBuddhistChronology

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

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

From duke at openjdk.java.net  Wed Oct 13 07:35:16 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 13 Oct 2021 07:35:16 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v2]
In-Reply-To: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
Message-ID: <DZpSTzGC0LcaK9FqwBCGbVIPUle1YEazznQZkfYOm58=.2f864fc5-3804-4180-be13-b7f1c2b5bed3@github.com>

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

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

 - 8274893: Update java.desktop classes to use try-with-resources
   close nested resources too
 - [PATCH] Use try-with-resources to close resources in java.desktop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5817/files
  - new: https://git.openjdk.java.net/jdk/pull/5817/files/6db4fd8e..13bdbc0d

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

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

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

From duke at openjdk.java.net  Wed Oct 13 07:40:51 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 13 Oct 2021 07:40:51 GMT
Subject: <i18n dev> RFR: 8274893: Update java.desktop classes to use
 try-with-resources [v2]
In-Reply-To: <ZuG9q2jWpcnH2eqlcc7QsHdJWz9-xOx_KkPRBb73JrE=.08ad0963-ff8b-4cac-8df2-7ace734d088e@github.com>
References: <_2AOzxRXvyozC4AbdieYrNLVEsNdnYJBLM3ExBBpIsA=.a82484c7-8ece-4233-a965-634e9e867cb7@github.com>
 <ZuG9q2jWpcnH2eqlcc7QsHdJWz9-xOx_KkPRBb73JrE=.08ad0963-ff8b-4cac-8df2-7ace734d088e@github.com>
Message-ID: <cROilBuMVej0JIKBrbA6lJocPUPmakpTdyEJepDaVhQ=.456c4e7d-1fcc-4cdc-9de3-0503e37f9936@github.com>

On Tue, 12 Oct 2021 06:16:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8274893: Update java.desktop classes to use try-with-resources
>>    close nested resources too
>>  - [PATCH] Use try-with-resources to close resources in java.desktop
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java line 587:
> 
>> 585:                     // Pending: verify character encoding spec for gconf
>> 586:                     StringBuilder sb = new StringBuilder();
>> 587:                     try (Reader reader = new InputStreamReader(url.openStream(), ISO_8859_1)) {
> 
> I did not check all code but look like in some places the close method was missed when a few streams were wrapped.
> Looks like in this place, the "url.openStream()" may be leaked if the constructor of InputStreamReader will throw an exception. Please check other places for similar issues.

updated

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

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

From wuyan at openjdk.java.net  Wed Oct 13 09:02:03 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Wed, 13 Oct 2021 09:02:03 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: <P328VysApETX_qWBMDHzX4f2zjxoxoZAtVBpl7NZ8Sc=.bcdcdfb1-43a3-4b18-b698-3f3cb0c6f1a5@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <X9ky2aTe5AzKj5vkv6bR4YPtkpNbI9wF-xAcpLy3xEw=.19fad7c2-a036-4b39-836a-73a447f27cf1@github.com>
 <P328VysApETX_qWBMDHzX4f2zjxoxoZAtVBpl7NZ8Sc=.bcdcdfb1-43a3-4b18-b698-3f3cb0c6f1a5@github.com>
Message-ID: <NDYDmCR1nS4hxCSJPvJiuSiuRhgX1A8nZIjpgwFn1qI=.b0fb20c1-53a8-431e-ab33-31b068dc148a@github.com>

On Mon, 11 Oct 2021 18:16:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Wu Yan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace realpath
>
> src/java.base/unix/native/libjava/TimeZone_md.c line 113:
> 
>> 111:     }
>> 112: }
>> 113: 
> 
> There are a few `*(right + 1)` references in the loops. Is there any possibility that it would run over the buffer?

It wouldn't run over the buffer. Here `end` points to `'\0'`. At line 94 and line 99,  `right` is less than `end`, so `right + 1` is at most `end`. At line 103, if `right` equals `end`, `*right != '\0'` will be false and `!(*right == '/' && *(right + 1) == '/')` will not executed.

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

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

From wuyan at openjdk.java.net  Wed Oct 13 09:06:52 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Wed, 13 Oct 2021 09:06:52 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: <P328VysApETX_qWBMDHzX4f2zjxoxoZAtVBpl7NZ8Sc=.bcdcdfb1-43a3-4b18-b698-3f3cb0c6f1a5@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <X9ky2aTe5AzKj5vkv6bR4YPtkpNbI9wF-xAcpLy3xEw=.19fad7c2-a036-4b39-836a-73a447f27cf1@github.com>
 <P328VysApETX_qWBMDHzX4f2zjxoxoZAtVBpl7NZ8Sc=.bcdcdfb1-43a3-4b18-b698-3f3cb0c6f1a5@github.com>
Message-ID: <qlycfPA4h_TAhjNItZAh0vQbQ-f11Nt3TWb0W3gMfyQ=.4461ac0f-93d5-4c6e-9081-a5819e9cc51b@github.com>

On Mon, 11 Oct 2021 18:18:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Wu Yan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   replace realpath
>
> src/java.base/unix/native/libjava/path_util.h line 31:
> 
>> 29: int collapsible(char *names);
>> 30: void splitNames(char *names, char **ix);
>> 31: void joinNames(char *names, int nc, char **ix);
> 
> Are these functions, `collapsible`, `splitNames` and `joinNames` have to be non-static?

You are right, thanks for your suggestions, I'll change these functions to static in next commit.

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

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

From wuyan at openjdk.java.net  Wed Oct 13 09:15:25 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Wed, 13 Oct 2021 09:15:25 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v3]
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: <O8D0OrdfSmXJ76gN1JmhdhrITVPpMDGf-WNeKcTPG50=.bde9a07e-89e9-4828-a45d-118199ca3909@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:

  change functions to be static

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

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

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

  Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 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 naoto at openjdk.java.net  Wed Oct 13 16:25:49 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 13 Oct 2021 16:25:49 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v3]
In-Reply-To: <O8D0OrdfSmXJ76gN1JmhdhrITVPpMDGf-WNeKcTPG50=.bde9a07e-89e9-4828-a45d-118199ca3909@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <O8D0OrdfSmXJ76gN1JmhdhrITVPpMDGf-WNeKcTPG50=.bde9a07e-89e9-4828-a45d-118199ca3909@github.com>
Message-ID: <x7HHqK6gxD1d4ftDaBTG6MeeCi5r61gbbPZgnmzMsgM=.624a8215-c329-4126-8355-a1aaec77b235@github.com>

On Wed, 13 Oct 2021 09:15:25 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:
> 
>   change functions to be static

Looks good. Thanks for the fix.

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

Marked as reviewed by naoto (Reviewer).

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

From itakiguchi at openjdk.java.net  Wed Oct 13 18:11:49 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 13 Oct 2021 18:11:49 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <K5os_X9ZHkyVFMGcF78gh5LEnJVFK0N3aOlyChRR3vM=.6f283f2d-dc8b-4c4c-ae7b-bf0d40d9dc80@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
 <K5os_X9ZHkyVFMGcF78gh5LEnJVFK0N3aOlyChRR3vM=.6f283f2d-dc8b-4c4c-ae7b-bf0d40d9dc80@github.com>
Message-ID: <TOTMhJzV2AWZX2IK2zfgSx8NBwvpMTwgRBZBVcd1IFM=.5d2cb8c5-5a48-42bf-a029-83f293aecded@github.com>

On Fri, 8 Oct 2021 21:07:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274544: Langtools command's usage were garbled on Japanese Windows
>
> BTW, does the PoC in the jshell bug report really causing the issue?
> 
> System.out.println("\u3042")
> 
> This is ASCII, so save/restore does not seem to cause any issues across JDKs with and without JEP400. Did you mean `Systemout.println("?")` instead?

Hello @naotoj .
Sorry I'm late.

I'd like to show you jshell issue step by step.
1. `System.out.println(...)` did not work if non-ASCII character was printed on JDK18-b13.
Because jshell output encoding was MS932, jshell agent output encoding was UTF-8
![jshell-932-01](https://user-images.githubusercontent.com/33543753/137185670-02bcec50-d5af-4515-b16b-2893094732d5.png)

2. Above fix was applied against `JShellToolProvider.java` only.
The issue was not fixed.
![jshell-932-02](https://user-images.githubusercontent.com/33543753/137186394-2c8bab09-7889-42d4-bbb7-2fb7b8a86a80.png)

3. Just applied lahodaj's fix `JShellToolBuilder.java`.
It worked fine as expected
![jshell-932-03](https://user-images.githubusercontent.com/33543753/137187148-d1eb0821-599a-4c27-a739-434ed21ff5b6.png)

4. I checked compatibility between JDK17 and this fix by using `/save` and `/open`
It seemed saved a.jsh's encoding was MS932
![jshell-932-04](https://user-images.githubusercontent.com/33543753/137187671-b271a772-790d-4925-aa84-dc003e904c34.png)

5. I think jshell and agent should use same `file.encoding` system property. I applied following fix.

--- a/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java
+++ b/src/jdk.jshell/share/classes/jdk/jshell/execution/JdiInitiator.java
@@ -27,6 +27,7 @@ package jdk.jshell.execution;
 import java.io.File;
 import java.io.IOException;
 import java.nio.charset.StandardCharsets;
+import java.nio.charset.Charset;
 import java.nio.file.Files;
 import java.util.ArrayList;
 import java.util.HashMap;
@@ -86,6 +87,17 @@ public class JdiInitiator {
             Map<String, String> customConnectorArgs) {
         this.remoteAgent = remoteAgent;
         this.connectTimeout = (int) (timeout * CONNECT_TIMEOUT_FACTOR);
+        if (!StandardCharsets.UTF_8.equals(Charset.defaultCharset())) {
+            boolean encodingFlag = true;
+            for (String s : remoteVMOptions.toArray(new String[0])) {
+                if (s.startsWith("-Dfile.encoding="))
+                    encodingFlag = false;
+            }
+            if (encodingFlag) {
+                remoteVMOptions.add("-Dfile.encoding="
+                    +Charset.defaultCharset().name());
+            }
+        }
         String connectorName
                 = isLaunch
                         ? "com.sun.jdi.CommandLineLaunch"


![image](https://user-images.githubusercontent.com/33543753/137186123-46ba46cb-e1ac-4a9f-ac77-05c2502cd368.png)

I think `JShellToolBuilder.java` and `JdiInitiator.java`.
Could you give me some suggestions ?

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

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

From naoto at openjdk.java.net  Wed Oct 13 18:42:52 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 13 Oct 2021 18:42:52 GMT
Subject: <i18n dev> RFR: 8275197: Remove unused fields in
 ThaiBuddhistChronology
In-Reply-To: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>
References: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>
Message-ID: <TWV4nQJ4bId-ujpIf21Jzr09OtG6Z4VpS8CNctasaZA=.eef96edf-909b-4773-8421-95dad2d44a2e@github.com>

On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Remove 3 unused HashMap's.
> Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html
> I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155

Marked as reviewed by naoto (Reviewer).

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

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

From wuyan at openjdk.java.net  Thu Oct 14 02:08:45 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Thu, 14 Oct 2021 02:08:45 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v4]
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: <xs4P6V5K9xmCkJzY5AKE4qGSLFlYoDNAWS7wmWE49O8=.e6ff5369-c05e-4f53-a151-4e661fae4fbd@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 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 timezone
 - change functions to be static
 - replace realpath
 - 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5327/files
  - new: https://git.openjdk.java.net/jdk/pull/5327/files/38177cd0..93cff3d1

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

  Stats: 1449026 lines in 13982 files changed: 735454 ins; 659127 del; 54445 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 rriggs at openjdk.java.net  Thu Oct 14 15:55:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 14 Oct 2021 15:55:53 GMT
Subject: <i18n dev> RFR: 8275197: Remove unused fields in
 ThaiBuddhistChronology
In-Reply-To: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>
References: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>
Message-ID: <kN6hEDmaVVhIPTqWhVITXI31N2aVSDv6Z3JpT8JG2iM=.330f1e23-59d8-4631-a32b-113aafa54fa0@github.com>

On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Remove 3 unused HashMap's.
> Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html
> I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155

Marked as reviewed by rriggs (Reviewer).

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

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

From iris at openjdk.java.net  Thu Oct 14 16:00:52 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 14 Oct 2021 16:00:52 GMT
Subject: <i18n dev> RFR: 8275197: Remove unused fields in
 ThaiBuddhistChronology
In-Reply-To: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>
References: <cYgxxtMEkgTjFqc4oUHZam1hGrkJeUTGXUUpnjZ5M4o=.fb103d21-b2e1-4b1a-bfb3-1b6e47f3a8d5@github.com>
Message-ID: <EazK3H2-s3T-IlMo2hjdMDXmAgytwmZ8TmQL5p-Mjfw=.86485f5c-42b9-44ff-9412-ec15456fc480@github.com>

On Tue, 12 Oct 2021 21:10:12 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Remove 3 unused HashMap's.
> Reported here https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-September/081866.html
> I did the similar PR to treetenbp and it was merged https://github.com/ThreeTen/threetenbp/pull/155

Marked as reviewed by iris (Reviewer).

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

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

From naoto at openjdk.java.net  Thu Oct 14 23:46:47 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 14 Oct 2021 23:46:47 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows
In-Reply-To: <kKgu64ppJfgbqLlBu4G-yis4_KfE66OeUdIdnqV-YPk=.3514a1d7-5aa4-4897-9924-a4b52f321484@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mj2Zsi5XXXFMxPV34Myy5FAdQILPuIKrmVtbh--dKQc=.8b5bba0d-f1b6-4f3b-bfe6-79592350f415@github.com>
 <B2epwQChX5YEaeLM9JwcX3H35Aonyz6reMNo6ovFhDw=.9b7dcec4-44b3-4f45-aa9c-d8118cc44387@github.com>
 <kKgu64ppJfgbqLlBu4G-yis4_KfE66OeUdIdnqV-YPk=.3514a1d7-5aa4-4897-9924-a4b52f321484@github.com>
Message-ID: <aX1dz7rsp8ndyKFJdGqzSXrCE9AGYY4EFj-uN5aQG2k=.7ab97678-0e34-457b-b104-380076680e0d@github.com>

On Mon, 4 Oct 2021 10:24:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Helllo @naotoj .
>> I used `System.console()` and `Console.charset()`.
>> 
>> The following executables had same issue, I fixed them.
>>> jar.exe, javac.exe, javadoc.exe, javap.exe, jdeps.exe, jlink.exe, jmod.exe, jpackage.exe
>> 
>> I could not find out the following executables had same issue or not
>>> jabswitch.exe, jcmd.exe, jfr.exe, jhsdb.exe, jimage.exe, jinfo.exe, jmap.exe, jps.exe, jrunscript.exe, jstack.exe, jstat.exe, jstatd.exe, kinit.exe, klist.exe, ktab.exe
>> 
>> The following executables worked fine.
>>> jarsigner.exe, java.exe, javaw.exe, jdb.exe, jdeprscan.exe, jshell.exe, keytool.exe, rmiregistry.exe, serialver.exe
>> 
>> The following executables were GUI apps
>>> jaccessinspector.exe, jaccesswalker.exe, jconsole.exe
>> 
>> These fixes don't have testcases.
>> Do you have any idea about testcase for this issue ?
>
> @takiguc - if JShell is still an issue, is there a chance you could try this:
> https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686
> 
> Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console.
> 
> Thanks!

I believe both @lahodaj and my proposed changes are needed, which I provided here: https://github.com/openjdk/jdk/commit/82a9033953655042480c90d388fcbc8053fc5ff5
Can you check this works?

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

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

From pbansal at openjdk.java.net  Fri Oct 15 06:15:48 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 15 Oct 2021 06:15:48 GMT
Subject: <i18n dev> RFR: 8275106: Cleanup Iterator usages in java.desktop
In-Reply-To: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
Message-ID: <4E4MEHcmE5532FqWb3v06usYf8nPv8CsozbUuDDY4y8=.18206b5f-9c49-4894-a42d-0bf2d8a85400@github.com>

On Fri, 8 Oct 2021 19:37:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
> We can use enhanced-for or Collection.removeIf

Marked as reviewed by pbansal (Reviewer).

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

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

From duke at openjdk.java.net  Fri Oct 15 07:12:51 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 15 Oct 2021 07:12:51 GMT
Subject: <i18n dev> Integrated: 8275106: Cleanup Iterator usages in
 java.desktop
In-Reply-To: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
References: <d9AJgybPungJT1OZe4YUnG2j6FAgQQN8aLR8rYCI4V0=.e94bf891-141c-4291-8526-f613f1c1e541@github.com>
Message-ID: <Wawivc3EC_OHayAriUG7yCOxebMAg0y9c7DtxHm5Xr0=.fbe7d3a1-f68f-41e6-b049-14d4842dcfea@github.com>

On Fri, 8 Oct 2021 19:37:35 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Cycles with 'Iterator' are error-prone. It's better to use more high-level code, which easier to read.
> We can use enhanced-for or Collection.removeIf

This pull request has now been integrated.

Changeset: 322b1301
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Pankaj Bansal <pbansal at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/322b1301061ba113dc5f7f3710dde2d80a18a14e
Stats:     115 lines in 18 files changed: 5 ins; 62 del; 48 mod

8275106: Cleanup Iterator usages in java.desktop

Reviewed-by: serb, pbansal

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

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

From mli at openjdk.java.net  Fri Oct 15 09:50:05 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 15 Oct 2021 09:50:05 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v4]
In-Reply-To: <xs4P6V5K9xmCkJzY5AKE4qGSLFlYoDNAWS7wmWE49O8=.e6ff5369-c05e-4f53-a151-4e661fae4fbd@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <xs4P6V5K9xmCkJzY5AKE4qGSLFlYoDNAWS7wmWE49O8=.e6ff5369-c05e-4f53-a151-4e661fae4fbd@github.com>
Message-ID: <j9usnUVZwg3JmOjtJcOaARKMZWdNqfNBwavyuEn4oPU=.53e72a7d-d6b0-417a-9489-5ecac0196672@github.com>

On Thu, 14 Oct 2021 02:08:45 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 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 timezone
>  - change functions to be static
>  - replace realpath
>  - 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux

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

> 80: 
> 81: /*
> 82:  * remove repeated path separators ('/') in the giving 'path'.

given?

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

> 87:     char *left = path;
> 88:     char *right = path;
> 89:     char *end = path + strlen(path);

"char* end"? better to align with existing code style

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

> 93:     for (; right < end; right++) {
> 94:         if (*right == '/' && *(right + 1) == '/') break;
> 95:     }

Is this for loop necessary? Seems it's ok to merge with the nested loop below.

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

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

From azvegint at openjdk.java.net  Fri Oct 15 14:07:58 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 15 Oct 2021 14:07:58 GMT
Subject: <i18n dev> Integrated: 8269698: Specification for methods of
 java.awt.im.InputContext should mention that they do nothing
In-Reply-To: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
References: <h9vUKsEt5TKAzrAgQWQdRlJLT0HW5MvugP70uLH6t_s=.1ca47f62-c9f3-423d-9540-f34bd4ce5452@github.com>
Message-ID: <UISM0m2UyDXYAMVpUpMDLeWPwkH2bD3yRJaUWq-d9pQ=.f2fa91bc-eee2-4175-ba73-29b322425880@github.com>

On Mon, 4 Oct 2021 14:54:27 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This fix simply describes that the `java.awt.im.InputContext` is a dummy implementation, which may not conform its spec.

This pull request has now been integrated.

Changeset: da8da3a1
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/da8da3a16148a750ce502f7b7281fe289acaef40
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8269698: Specification for methods of java.awt.im.InputContext should mention that they do nothing

Reviewed-by: serb

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

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

From itakiguchi at openjdk.java.net  Mon Oct 18 17:47:55 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 18 Oct 2021 17:47:55 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows
In-Reply-To: <aX1dz7rsp8ndyKFJdGqzSXrCE9AGYY4EFj-uN5aQG2k=.7ab97678-0e34-457b-b104-380076680e0d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mj2Zsi5XXXFMxPV34Myy5FAdQILPuIKrmVtbh--dKQc=.8b5bba0d-f1b6-4f3b-bfe6-79592350f415@github.com>
 <B2epwQChX5YEaeLM9JwcX3H35Aonyz6reMNo6ovFhDw=.9b7dcec4-44b3-4f45-aa9c-d8118cc44387@github.com>
 <kKgu64ppJfgbqLlBu4G-yis4_KfE66OeUdIdnqV-YPk=.3514a1d7-5aa4-4897-9924-a4b52f321484@github.com>
 <aX1dz7rsp8ndyKFJdGqzSXrCE9AGYY4EFj-uN5aQG2k=.7ab97678-0e34-457b-b104-380076680e0d@github.com>
Message-ID: <vDfDWgHnuT5vGWFvJ1BQ9VJiSQH15qtslLw3mOfEq-w=.7ea333af-1e86-4615-9e8b-e1f5b692205b@github.com>

On Thu, 14 Oct 2021 23:43:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> @takiguc - if JShell is still an issue, is there a chance you could try this:
>> https://github.com/lahodaj/jdk/commit/cfa6b3eebbc22c5a48d31cfd692ff98690653686
>> 
>> Not sure if it will help, but it might (this won't change the default charset, but could send the output in a sensible encoding for the console.
>> 
>> Thanks!
>
> I believe both @lahodaj and my proposed changes are needed, which I provided here: https://github.com/openjdk/jdk/commit/82a9033953655042480c90d388fcbc8053fc5ff5
> Can you check this works?

Hello @naotoj .
[82a9033](https://github.com/openjdk/jdk/commit/82a9033953655042480c90d388fcbc8053fc5ff5) worked on Windows platform, then I got your point.
To minimize changes, I think I should create new method and call from JShellToolBuilder.java and JShellToolProvider.java.

    static PrintStream derivePrintStream(PrintStream ps) {
        if (Charset.defaultCharset().equals(NATIVE_CHARSET)) {
            return ps;
        } else {
            return new PrintStream(new WriterOutputStream(
                new OutputStreamWriter(ps, NATIVE_CHARSET), Charset.defaultCharset()));
        }
    }


Additionally, I tested this issue on non-UTF-8 platform like RHEL7/CentOS7 EUC locale (ja_JP.eucjp).
It seemed JLine's terminal's encoding was still UTF-8.
I could not input Japanese character as expected, also Cut & Paste with Japanese string did not work.
In my investigation, Charset.defaultCharset() was used on AbstractTerminal.java
https://github.com/openjdk/jdk/blob/master/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java#L55-L62
I should be like,

        this.encoding = encoding != null ? encoding : nativeCharset;

(JLine was upgraded by b19, I need to rebase if it's required)

One more thing,
For Inter-Process Communication between jshell front-end and agent, I think default charset should be same for non UTF-8 environment.
I think JdiInitiator.java should be modified.

Please give me your suggestion.

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

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

From naoto at openjdk.java.net  Mon Oct 18 23:28:47 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 18 Oct 2021 23:28:47 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
Message-ID: <r73M8nhDJrhERvhn1xEJ10XSxl8lftCcNKKXDTlI8qE=.3562a8a7-c102-4999-b51f-c1279fd34f0b@github.com>

On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274544: Langtools command's usage were garbled on Japanese Windows

this.encoding = encoding != null ? encoding : nativeCharset;

I am not familiar with `JLine`, but if it is working in a Console, it should refer to `Console.charset()` first.
As to `JdiInitiator`, not sure I understand the situation. Would you mind providing some examples that would cause problems?

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

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

From jjg at openjdk.java.net  Tue Oct 19 01:29:47 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 19 Oct 2021 01:29:47 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
Message-ID: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com>

On Wed, 6 Oct 2021 05:04:28 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274544: Langtools command's usage were garbled on Japanese Windows

This is pretty ugly code to be replicating so many times.

What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`?  You should not assume that `System.out` and `System.err` will always refer to the console.

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

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

From wuyan at openjdk.java.net  Tue Oct 19 04:08:12 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Tue, 19 Oct 2021 04:08:12 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v5]
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: <cktDB_uLM1b7Qk0RkwjH8RbnVtCRmftVJ4eVi6G740Q=.a2529694-6dfb-405c-952f-737ad3031d33@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:

  fix code style

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5327/files
  - new: https://git.openjdk.java.net/jdk/pull/5327/files/93cff3d1..ba9cc656

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

  Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 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  Tue Oct 19 04:17:01 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Tue, 19 Oct 2021 04:17:01 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v4]
In-Reply-To: <j9usnUVZwg3JmOjtJcOaARKMZWdNqfNBwavyuEn4oPU=.53e72a7d-d6b0-417a-9489-5ecac0196672@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <xs4P6V5K9xmCkJzY5AKE4qGSLFlYoDNAWS7wmWE49O8=.e6ff5369-c05e-4f53-a151-4e661fae4fbd@github.com>
 <j9usnUVZwg3JmOjtJcOaARKMZWdNqfNBwavyuEn4oPU=.53e72a7d-d6b0-417a-9489-5ecac0196672@github.com>
Message-ID: <iDjxY09LKVkzFy4MiuP7K-vufWrVy8mskvw0o-75xkI=.d8bdfcc2-751f-4e6a-ae24-6425a5cc9fae@github.com>

On Fri, 15 Oct 2021 07:03:18 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Wu Yan 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 timezone
>>  - change functions to be static
>>  - replace realpath
>>  - 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux
>
> src/java.base/unix/native/libjava/TimeZone_md.c line 82:
> 
>> 80: 
>> 81: /*
>> 82:  * remove repeated path separators ('/') in the giving 'path'.
> 
> given?

Thanks, fix it.

> src/java.base/unix/native/libjava/TimeZone_md.c line 89:
> 
>> 87:     char *left = path;
>> 88:     char *right = path;
>> 89:     char *end = path + strlen(path);
> 
> "char* end"? better to align with existing code style

OK, fixed it.

> src/java.base/unix/native/libjava/TimeZone_md.c line 95:
> 
>> 93:     for (; right < end; right++) {
>> 94:         if (*right == '/' && *(right + 1) == '/') break;
>> 95:     }
> 
> Is this for loop necessary? Seems it's ok to merge with the nested loop below.

Thanks for your suggestion, this for loop is indeed unnecessary. Removed it.

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

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

From mli at openjdk.java.net  Tue Oct 19 07:06:52 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 19 Oct 2021 07:06:52 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v5]
In-Reply-To: <cktDB_uLM1b7Qk0RkwjH8RbnVtCRmftVJ4eVi6G740Q=.a2529694-6dfb-405c-952f-737ad3031d33@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <cktDB_uLM1b7Qk0RkwjH8RbnVtCRmftVJ4eVi6G740Q=.a2529694-6dfb-405c-952f-737ad3031d33@github.com>
Message-ID: <Q335M70o9Hl8Mqq5IubFUgRsNDL5owg9aPMnaT1IBkw=.1f484447-4110-4e0d-b17c-ac0613669d92@github.com>

On Tue, 19 Oct 2021 04:08:12 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:
> 
>   fix code style

looks good

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

Marked as reviewed by mli (Reviewer).

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

From prr at openjdk.java.net  Wed Oct 20 04:19:30 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 04:19:30 GMT
Subject: <i18n dev> RFR: 8198336: java/awt/FontMetrics/FontCrash.java fails
 in headless mode
Message-ID: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>

The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.

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

Commit messages:
 - 8198336: java/awt/FontMetrics/FontCrash.java

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

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

From serb at openjdk.java.net  Wed Oct 20 07:04:06 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 20 Oct 2021 07:04:06 GMT
Subject: <i18n dev> RFR: 8198336: java/awt/FontMetrics/FontCrash.java
 fails in headless mode
In-Reply-To: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
Message-ID: <1lDUR82e_OvDR55Au0p-i1MS6JI5-4TuHwUnlwNXqeU=.383aa1b2-83fb-4af4-8495-3173b31ab072@github.com>

On Wed, 20 Oct 2021 04:12:46 GMT, Phil Race <prr at openjdk.org> wrote:

> The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.

src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java line 696:

> 694:             && ((SunFontManager) fm).usePlatformFontMetrics()) {
> 695:             return WFontMetrics.getFontMetrics(font);
> 696:         }

The whole method can be removed? it is identical to the parent now.

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

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

From prr at openjdk.java.net  Wed Oct 20 16:48:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 16:48:41 GMT
Subject: <i18n dev> RFR: 8198336: java/awt/FontMetrics/FontCrash.java
 fails in headless mode [v2]
In-Reply-To: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
Message-ID: <e4B62Qda_-qetOo2Nk3yEa-vKpmHcLHxglPpTAygkw4=.ea73dde9-d9b8-4d34-ad41-eaa8739a57ff@github.com>

> The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.

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

  8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6027/files
  - new: https://git.openjdk.java.net/jdk/pull/6027/files/c86b4ef3..74583d37

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

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

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

From prr at openjdk.java.net  Wed Oct 20 16:48:45 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 16:48:45 GMT
Subject: <i18n dev> RFR: 8198336: java/awt/FontMetrics/FontCrash.java
 fails in headless mode [v2]
In-Reply-To: <1lDUR82e_OvDR55Au0p-i1MS6JI5-4TuHwUnlwNXqeU=.383aa1b2-83fb-4af4-8495-3173b31ab072@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
 <1lDUR82e_OvDR55Au0p-i1MS6JI5-4TuHwUnlwNXqeU=.383aa1b2-83fb-4af4-8495-3173b31ab072@github.com>
Message-ID: <5seTVbfbbL5Jh6qp7LIrgg5hKDjy4xnBb6rlw6vdHSA=.78f55c23-ddc4-47c5-8e7b-322728202f74@github.com>

On Wed, 20 Oct 2021 06:58:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode
>
> src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java line 696:
> 
>> 694:             && ((SunFontManager) fm).usePlatformFontMetrics()) {
>> 695:             return WFontMetrics.getFontMetrics(font);
>> 696:         }
> 
> The whole method can be removed? it is identical to the parent now.

true, I can't see any reason to keep it.

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

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

From serb at openjdk.java.net  Thu Oct 21 01:38:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 21 Oct 2021 01:38:08 GMT
Subject: <i18n dev> RFR: 8198336: java/awt/FontMetrics/FontCrash.java
 fails in headless mode [v2]
In-Reply-To: <e4B62Qda_-qetOo2Nk3yEa-vKpmHcLHxglPpTAygkw4=.ea73dde9-d9b8-4d34-ad41-eaa8739a57ff@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
 <e4B62Qda_-qetOo2Nk3yEa-vKpmHcLHxglPpTAygkw4=.ea73dde9-d9b8-4d34-ad41-eaa8739a57ff@github.com>
Message-ID: <WkudWu7KD8qzNueBv6BrImWwBNH69170bjgNtkh3JH4=.93a3bc41-fb04-4069-b041-28a16d2509f6@github.com>

On Wed, 20 Oct 2021 16:48:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode

Marked as reviewed by serb (Reviewer).

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

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

From itakiguchi at openjdk.java.net  Thu Oct 21 16:24:03 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 21 Oct 2021 16:24:03 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v3]
In-Reply-To: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
 <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com>
Message-ID: <n-ITnhSjRwM4-AmCy91-Mdkw8AmcjGviwPSoM7v3XDM=.f40c6a97-677e-4a4a-957f-6ef4b6e3414c@github.com>

On Tue, 19 Oct 2021 01:26:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274544: Langtools command's usage were garbled on Japanese Windows
>
> This is pretty ugly code to be replicating so many times.
> 
> What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`?  You should not assume that `System.out` and `System.err` will always refer to the console.

@jonathan-gibbons  I appreciate your comment.
I'd like to confirm something.
> This is pretty ugly code to be replicating so many times.
> What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`? You should not assume that `System.out` and `System.err` will always refer to the console.

I was confused since the fixed code did not call System.out/System.err directly.
I tried following code on Japanese Windows.

import java.io.*;
import java.nio.charset.*;

public class OutputCheck {
    public static void main(String[] args) throws Exception {
         String s = "\u3042";
         System.out.println("[1]:"+s);
         PrintStream ps = System.out;
         System.setOut(new PrintStream(System.out));
         System.out.println("[2]:"+s);
         ps.println("[3]:"+s);
         System.setOut(new PrintStream(System.out, true, Charset.forName(System.getProperty("native.encoding"))));
         System.out.println("[4]:"+s);
    }
}

Output is:

> jdk-18-b14\bin\java OutputCheck.java
[1]:?
[2]:??
[3]:?
[4]:?

[2] refers default charset (UTF-8)
[3] is same as [1]
[4] specifies native.encoding system encoding

Could you explain more detail ?

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

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

From wuyan at openjdk.java.net  Fri Oct 22 01:40:02 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Fri, 22 Oct 2021 01:40:02 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: <EzYdLoUXV1PF46WWcsgeLoFy2E88Y8-s7I0GLRJxqfo=.f36a8bfb-e3d7-4e76-bce4-35dd893c9861@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <EzYdLoUXV1PF46WWcsgeLoFy2E88Y8-s7I0GLRJxqfo=.f36a8bfb-e3d7-4e76-bce4-35dd893c9861@github.com>
Message-ID: <asOgWsBFuSgwooi2k99m4KM3VBVLUBXT_kpcbP8XjIk=.b6ed9a7b-4332-42ee-8912-47ffb01b3a7f@github.com>

On Wed, 1 Sep 2021 13:39:46 GMT, Naoto Sato <naoto 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.

Hi, @naotoj, I pushed the new commit, do you need to review again?

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

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

From naoto at openjdk.java.net  Fri Oct 22 16:24:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 22 Oct 2021 16:24:05 GMT
Subject: <i18n dev> RFR: 8273111: Default timezone should return zone ID
 if /etc/localtime is valid but not canonicalization on linux [v5]
In-Reply-To: <cktDB_uLM1b7Qk0RkwjH8RbnVtCRmftVJ4eVi6G740Q=.a2529694-6dfb-405c-952f-737ad3031d33@github.com>
References: <6gmVj3r1hjhG5jvo_dSly3ShNnZZSCn-NIjtnvSySrk=.a88def27-7b80-425b-9ab8-2f94f5004b47@github.com>
 <cktDB_uLM1b7Qk0RkwjH8RbnVtCRmftVJ4eVi6G740Q=.a2529694-6dfb-405c-952f-737ad3031d33@github.com>
Message-ID: <k5d2Y4yCrQCX88hZJ4XnhZUfOKJwRZy3Z0bCTcSIYGI=.8e143bd4-4c82-40cf-8dfe-286d3aa2fbf9@github.com>

On Tue, 19 Oct 2021 04:08:12 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:
> 
>   fix code style

Looks good. Thanks for the fix.

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

Marked as reviewed by naoto (Reviewer).

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

From wuyan at openjdk.java.net  Fri Oct 22 16:26:21 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Fri, 22 Oct 2021 16:26:21 GMT
Subject: <i18n dev> Integrated: 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: <NE1jygx6y3DugcfxslD_gNMKIYRX2F0oA-1u36A-z0s=.a60af222-de82-46ae-a6b4-395059140636@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

This pull request has now been integrated.

Changeset: 88bbf3c2
Author:    Wu Yan <wuyan at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/88bbf3c2e6ac9f6d88cbb361cfbb4c16bb8eafc1
Stats:     352 lines in 4 files changed: 203 ins; 145 del; 4 mod

8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux

Co-authored-by: Sun Jianye <sunjianye at huawei.com>
Reviewed-by: naoto, mli

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

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

From prr at openjdk.java.net  Fri Oct 22 17:25:13 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 22 Oct 2021 17:25:13 GMT
Subject: <i18n dev> Integrated: 8198336: java/awt/FontMetrics/FontCrash.java
 fails in headless mode
In-Reply-To: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
References: <_BhBTiMOOEz6gpbwIxH-tsUoPxt2Xja3rETAshyZA8s=.d144e7d4-9540-4bbe-b0c4-e5f33d0cb2bc@github.com>
Message-ID: <5zBi2eC103VihM-KJm7B1TJFLUDJuIEsW50-AD9H3U8=.8aec4f7c-e861-4fc3-af81-9aea2a9fa357@github.com>

On Wed, 20 Oct 2021 04:12:46 GMT, Phil Race <prr at openjdk.org> wrote:

> The code this test exercises is very obsolete. So this removes the test that triggers it along with that code.

This pull request has now been integrated.

Changeset: 6523c558
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6523c558d92dedf350576126960dee6cff8f6067
Stats:     98 lines in 5 files changed: 0 ins; 98 del; 0 mod

8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode

Reviewed-by: serb

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

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

From redestad at openjdk.java.net  Mon Oct 25 11:31:14 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 25 Oct 2021 11:31:14 GMT
Subject: <i18n dev> RFR: 8275863: Use encodeASCII for ASCII-compatible
 DoubleByte encodings
Message-ID: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>

Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`:

Before:

Benchmark                   (size)      (type)  Mode  Cnt   Score   Error  Units
CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30   3.021 ? 0.120  us/op
CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  47.793 ? 1.942  us/op
CharsetEncodeDecode.encode   16384      GB2312  avgt   30  49.598 ? 2.006  us/op
CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  68.709 ? 5.019  us/op
CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  48.033 ? 1.651  us/op


Patched:

Benchmark                   (size)      (type)  Mode  Cnt  Score   Error  Units
CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30  2.856 ? 0.078  us/op
CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  5.287 ? 0.209  us/op
CharsetEncodeDecode.encode   16384      GB2312  avgt   30  5.490 ? 0.251  us/op
CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  7.657 ? 0.368  us/op
CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  5.718 ? 0.267  us/op


The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations.

Testing: tier1-3

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

Commit messages:
 - Use field directly
 - Grant accessClassInPackage.jdk.internal.access permission to jdk.charsets module
 - 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings

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

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

From itakiguchi at openjdk.java.net  Mon Oct 25 14:20:52 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 25 Oct 2021 14:20:52 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v4]
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <Vn7pob-3KzZt43rtC4HzR1_ytRofUvxD8CYthmhbwHE=.63e89965-c2be-4327-8585-919588a82ec5@github.com>

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

Ichiroh Takiguchi 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:

 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - Langtools command's usage were grabled on Japanese Windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5771/files
  - new: https://git.openjdk.java.net/jdk/pull/5771/files/4427d87c..e2a87848

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

  Stats: 35926 lines in 1051 files changed: 24201 ins; 7865 del; 3860 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771

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

From itakiguchi at openjdk.java.net  Mon Oct 25 16:04:13 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 25 Oct 2021 16:04:13 GMT
Subject: <i18n dev> RFR: 8274544: Langtools command's usage were garbled
 on Japanese Windows [v4]
In-Reply-To: <Vn7pob-3KzZt43rtC4HzR1_ytRofUvxD8CYthmhbwHE=.63e89965-c2be-4327-8585-919588a82ec5@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <Vn7pob-3KzZt43rtC4HzR1_ytRofUvxD8CYthmhbwHE=.63e89965-c2be-4327-8585-919588a82ec5@github.com>
Message-ID: <mYaN5oqrsoYsUokZhYtqXaFtWYIVhBG3w5tfYkmz7uY=.cfbb6486-1e3f-41fd-9d62-4a53fb6e81b0@github.com>

On Mon, 25 Oct 2021 14:20:52 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi 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:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Terminal setting

$ locale
LANG=ja_JP.eucjp
LC_CTYPE="ja_JP.eucjp"
LC_NUMERIC="ja_JP.eucjp"
LC_TIME="ja_JP.eucjp"
LC_COLLATE="ja_JP.eucjp"
LC_MONETARY="ja_JP.eucjp"
LC_MESSAGES="ja_JP.eucjp"
LC_PAPER="ja_JP.eucjp"
LC_NAME="ja_JP.eucjp"
LC_ADDRESS="ja_JP.eucjp"
LC_TELEPHONE="ja_JP.eucjp"
LC_MEASUREMENT="ja_JP.eucjp"
LC_IDENTIFICATION="ja_JP.eucjp"
LC_ALL=

Java testcase by using Scanner.

$ cat scan.java 
import java.util.*;

public class scan {
  public static void main(String[] args) throws Exception {
    System.out.println("Please input some characters:");
    Scanner scanner = new Scanner(System.in);
    System.out.println(scanner.next());
  }
}
$ ~/jdk-18-b19/bin/java scan.java
Please input some characters:
?????
??????????

When `src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/AbstractTerminal.java` is modified

$ jshell
|  JShell????? -- ?????18-internal
|  ??????????????????: /help intro

jshell> import java.nio.charset.*

jshell> System.out.println(System.getProperty("native.encoding"))
EUC-JP-LINUX

jshell> System.out.println(Charset.defaultCharset())
UTF-8

jshell> var scan = new Scanner(System.in)
scan ==> java.util.Scanner[delimiters=\p{javaWhitespace}+] ... \E][infinity string=\Q?\E]

jshell> var s = scan.next()
?????
s ==> "?????"

jshell> System.out.println(s)
?????

jshell> /exit
|  ?????
$

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

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

From naoto at openjdk.java.net  Mon Oct 25 16:18:17 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 25 Oct 2021 16:18:17 GMT
Subject: <i18n dev> RFR: 8275767: JDK source code contains redundant boolean
 operations in jdk.charsets
Message-ID: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>

Trivial clean-up.

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

Commit messages:
 - 8275767: JDK source code contains redundant boolean operations in jdk.charsets

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

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

From lancea at openjdk.java.net  Mon Oct 25 16:39:03 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 25 Oct 2021 16:39:03 GMT
Subject: <i18n dev> RFR: 8275767: JDK source code contains redundant
 boolean operations in jdk.charsets
In-Reply-To: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
References: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
Message-ID: <p4mhxyhPdhtJVhchs08R_5hepw-_srr7iw1F0j-wHAM=.0701f023-acc3-4e0e-a8c7-1c6dc6d1efa4@github.com>

On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial clean-up.

Marked as reviewed by lancea (Reviewer).

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

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

From rriggs at openjdk.java.net  Mon Oct 25 17:01:03 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 25 Oct 2021 17:01:03 GMT
Subject: <i18n dev> RFR: 8275767: JDK source code contains redundant
 boolean operations in jdk.charsets
In-Reply-To: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
References: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
Message-ID: <z29eLalIullCx_iQeKA9y_TgB31AJ5pk_gFBVXY3uik=.04c671f8-b9eb-47f9-8bc8-a06c9e37f416@github.com>

On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial clean-up.

Given that the code has been that way for a *long time*, did you check that both paths work as intended and that tests exist for both paths?

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

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

From naoto at openjdk.java.net  Mon Oct 25 17:19:11 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 25 Oct 2021 17:19:11 GMT
Subject: <i18n dev> RFR: 8275767: JDK source code contains redundant
 boolean operations in jdk.charsets
In-Reply-To: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
References: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
Message-ID: <hMoG1EMjp0ElxpixBq9fzbFEiJW6aLY2JP-br2DN7ps=.46d81772-245c-4e83-9e7e-b7ba65a6cde7@github.com>

On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial clean-up.

No, I did not check. I simply removed the `true &&` as it is logically correct. There's a test specifying `IBM964` in `sun.nio.cs.TestIBMBugs.java`, but not sure it tests both paths or not.

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

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

From rriggs at openjdk.java.net  Mon Oct 25 18:04:11 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 25 Oct 2021 18:04:11 GMT
Subject: <i18n dev> RFR: 8275767: JDK source code contains redundant
 boolean operations in jdk.charsets
In-Reply-To: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
References: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
Message-ID: <TxSbpboEMijgnQGbZlILTfT2SwPWYKaDfaNjtFOAQmk=.79987c75-3521-4f15-a821-46523e2f45d8@github.com>

On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial clean-up.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From iris at openjdk.java.net  Mon Oct 25 18:08:04 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 25 Oct 2021 18:08:04 GMT
Subject: <i18n dev> RFR: 8275767: JDK source code contains redundant
 boolean operations in jdk.charsets
In-Reply-To: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
References: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
Message-ID: <qcweP12PQ2rFxfXAxoGvsmJW9BAf311QtqjnTPXSfug=.baca03d3-25c0-4beb-b457-a5b11251d56c@github.com>

On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial clean-up.

Marked as reviewed by iris (Reviewer).

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

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

From naoto at openjdk.java.net  Tue Oct 26 12:36:20 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 26 Oct 2021 12:36:20 GMT
Subject: <i18n dev> Integrated: 8275767: JDK source code contains redundant
 boolean operations in jdk.charsets
In-Reply-To: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
References: <ij_mbxbAuPWOA29j5TsQyBKuoMyr68w5HQqCVpHmEQY=.5ba5aae2-56ef-4e36-b6ca-eab7a7cacebb@github.com>
Message-ID: <kkYS5GSkTGrtRcGG9hvKCob2lO2Wg0JWrqJFafJTmaQ=.58f01855-4c85-4491-b612-27cba829f7ed@github.com>

On Mon, 25 Oct 2021 16:08:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial clean-up.

This pull request has now been integrated.

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

8275767: JDK source code contains redundant boolean operations in jdk.charsets

Reviewed-by: lancea, rriggs, iris

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

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

From naoto at openjdk.java.net  Tue Oct 26 18:26:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 26 Oct 2021 18:26:09 GMT
Subject: <i18n dev> RFR: 8275863: Use encodeASCII for ASCII-compatible
 DoubleByte encodings
In-Reply-To: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
References: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
Message-ID: <yT5EIgSJ-CYuhZrMbNKccWfVwnQ9y75_FiN1F0p4lXk=.a5d59522-e29c-4e74-8af3-82b9274987f4@github.com>

On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`:
> 
> Before:
> 
> Benchmark                   (size)      (type)  Mode  Cnt   Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30   3.021 ? 0.120  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  47.793 ? 1.942  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  49.598 ? 2.006  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  68.709 ? 5.019  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  48.033 ? 1.651  us/op
> 
> 
> Patched:
> 
> Benchmark                   (size)      (type)  Mode  Cnt  Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30  2.856 ? 0.078  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  5.287 ? 0.209  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  5.490 ? 0.251  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  7.657 ? 0.368  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  5.718 ? 0.267  us/op
> 
> 
> The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations.
> 
> Testing: tier1-3

Looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From rriggs at openjdk.java.net  Tue Oct 26 19:00:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 26 Oct 2021 19:00:15 GMT
Subject: <i18n dev> RFR: 8275863: Use encodeASCII for ASCII-compatible
 DoubleByte encodings
In-Reply-To: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
References: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
Message-ID: <O-X5Ls5Xi5GhdICQlTh1vt8DVAjdCiY04iWgWO-Gw3E=.b9fdcbf4-8202-4e2f-ae35-33af490bcb87@github.com>

On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`:
> 
> Before:
> 
> Benchmark                   (size)      (type)  Mode  Cnt   Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30   3.021 ? 0.120  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  47.793 ? 1.942  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  49.598 ? 2.006  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  68.709 ? 5.019  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  48.033 ? 1.651  us/op
> 
> 
> Patched:
> 
> Benchmark                   (size)      (type)  Mode  Cnt  Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30  2.856 ? 0.078  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  5.287 ? 0.209  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  5.490 ? 0.251  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  7.657 ? 0.368  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  5.718 ? 0.267  us/op
> 
> 
> The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations.
> 
> Testing: tier1-3

Marked as reviewed by rriggs (Reviewer).

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

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

From alanb at openjdk.java.net  Tue Oct 26 19:08:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 26 Oct 2021 19:08:15 GMT
Subject: <i18n dev> RFR: 8275863: Use encodeASCII for ASCII-compatible
 DoubleByte encodings
In-Reply-To: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
References: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
Message-ID: <7GvaEmUjCwTZUQVIo09tAKMT1rwqsmfdZy-gA-Q5fk0=.44e2b58d-573f-4fcd-bc83-5e59fad9a422@github.com>

On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`:
> 
> Before:
> 
> Benchmark                   (size)      (type)  Mode  Cnt   Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30   3.021 ? 0.120  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  47.793 ? 1.942  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  49.598 ? 2.006  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  68.709 ? 5.019  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  48.033 ? 1.651  us/op
> 
> 
> Patched:
> 
> Benchmark                   (size)      (type)  Mode  Cnt  Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30  2.856 ? 0.078  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  5.287 ? 0.209  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  5.490 ? 0.251  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  7.657 ? 0.368  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  5.718 ? 0.267  us/op
> 
> 
> The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations.
> 
> Testing: tier1-3

Good work

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

Marked as reviewed by alanb (Reviewer).

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

From redestad at openjdk.java.net  Wed Oct 27 10:11:16 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 27 Oct 2021 10:11:16 GMT
Subject: <i18n dev> RFR: 8275863: Use encodeASCII for ASCII-compatible
 DoubleByte encodings
In-Reply-To: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
References: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
Message-ID: <YGi8s-KQveLmX33_XcksHZFWzEgofpt0UI7JlV9VcjU=.b1f5f870-87a3-4e4f-a061-31c798a96bfc@github.com>

On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`:
> 
> Before:
> 
> Benchmark                   (size)      (type)  Mode  Cnt   Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30   3.021 ? 0.120  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  47.793 ? 1.942  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  49.598 ? 2.006  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  68.709 ? 5.019  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  48.033 ? 1.651  us/op
> 
> 
> Patched:
> 
> Benchmark                   (size)      (type)  Mode  Cnt  Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30  2.856 ? 0.078  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  5.287 ? 0.209  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  5.490 ? 0.251  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  7.657 ? 0.368  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  5.718 ? 0.267  us/op
> 
> 
> The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations.
> 
> Testing: tier1-3

Thanks for reviewing!

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

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

From redestad at openjdk.java.net  Wed Oct 27 10:11:16 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 27 Oct 2021 10:11:16 GMT
Subject: <i18n dev> Integrated: 8275863: Use encodeASCII for
 ASCII-compatible DoubleByte encodings
In-Reply-To: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
References: <HLCTxBqIzs2Pmx8LQcKCwyBvxB04OLVL33L_mwX1fB4=.6d25c284-ea66-4740-97b1-f6c830a8be1a@github.com>
Message-ID: <gx-bDdmj8wXLKZ1qTYGdCzb6F0HNXgZI5QZg00PPsmk=.85c1ad24-f487-4ce1-aa07-482e111c6436@github.com>

On Mon, 25 Oct 2021 10:16:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Enhance ASCII-compatible `DoubleByte` encodings to make use of the `StringCoding.implEncodeAsciiArray` intrinsic, which makes many such `CharsetEncoder`s encode ASCII text at speeds comparable to most single-byte encoders - and also more in line with how well these charsets behave when calling `String.getBytes`:
> 
> Before:
> 
> Benchmark                   (size)      (type)  Mode  Cnt   Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30   3.021 ? 0.120  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  47.793 ? 1.942  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  49.598 ? 2.006  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  68.709 ? 5.019  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  48.033 ? 1.651  us/op
> 
> 
> Patched:
> 
> Benchmark                   (size)      (type)  Mode  Cnt  Score   Error  Units
> CharsetEncodeDecode.encode   16384  ISO-8859-1  avgt   30  2.856 ? 0.078  us/op
> CharsetEncodeDecode.encode   16384   Shift-JIS  avgt   30  5.287 ? 0.209  us/op
> CharsetEncodeDecode.encode   16384      GB2312  avgt   30  5.490 ? 0.251  us/op
> CharsetEncodeDecode.encode   16384      EUC-JP  avgt   30  7.657 ? 0.368  us/op
> CharsetEncodeDecode.encode   16384      EUC-KR  avgt   30  5.718 ? 0.267  us/op
> 
> 
> The `isASCIICompatible` predicate on `DoubleByte` was added in JEP 254 for the purpose of implementing such ASCII fast-paths, but is only used in what is now `String.encodeWithEncoder` to speed up `String.getBytes(...)` operations.
> 
> Testing: tier1-3

This pull request has now been integrated.

Changeset: 6c05cc9d
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6c05cc9d15fb6014b8293a66ef132f3461badca1
Stats:     35 lines in 5 files changed: 24 ins; 4 del; 7 mod

8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings

Reviewed-by: naoto, rriggs, alanb

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

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

From duke at openjdk.java.net  Wed Oct 27 16:21:20 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 27 Oct 2021 16:21:20 GMT
Subject: <i18n dev> Integrated: 8274879: Replace uses of StringBuffer with
 StringBuilder within java.base classes
In-Reply-To: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
References: <YMy-vvoApCDpBGDU0YxNoatbb0P5T1u_H0CptQ6JFPU=.4438c473-9ab5-4d87-bf00-2b93929ad6cd@github.com>
Message-ID: <9BGa0d9dkCjuAJV2PJrCCMDAMGjW6WSkDGeuWSn3Xh8=.6eacd128-16e4-4d80-a9a4-310e9107f6af@github.com>

On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance
> 
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029)  I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated.

This pull request has now been integrated.

Changeset: 9a3e9542
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a3e9542997860de79d07a4411b1007e9cd5c348
Stats:     31 lines in 11 files changed: 0 ins; 0 del; 31 mod

8274879: Replace uses of StringBuffer with StringBuilder within java.base classes

Reviewed-by: naoto

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

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

From ysatowse at openjdk.java.net  Fri Oct 29 05:03:43 2021
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 29 Oct 2021 05:03:43 GMT
Subject: <i18n dev> RFR: 8275766: (tz) Update Timezone Data to 2021e
Message-ID: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>

Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
The fix has passed all relevant JTREG regression tests and JCK tests. 

8275754: (tz) Update Timezone Data to 2021d
8275849: TestZoneInfo310.java fails with tzdata2021e

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

Commit messages:
 - 8275754: (tz) Update Timezone Data to 2021d

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

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

From naoto at openjdk.java.net  Fri Oct 29 05:03:43 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 29 Oct 2021 05:03:43 GMT
Subject: <i18n dev> RFR: 8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
References: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
Message-ID: <q2L25bDqlCYyZ1HQhap1vGmryDzEvKK8FPea1QeJy54=.9fee876e-f8ee-4c8e-8a5a-e4393c28b8d5@github.com>

On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests. 
> 
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fails with tzdata2021e

Marked as reviewed by naoto (Reviewer).

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

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

From iris at openjdk.java.net  Fri Oct 29 06:39:10 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 29 Oct 2021 06:39:10 GMT
Subject: <i18n dev> RFR: 8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
References: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
Message-ID: <BSyj-86FFYMG9C6SObf0-fenCEL4-1PYpotyXfPkbT8=.4f9bb8d1-7164-414f-a405-799e056aacde@github.com>

On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests. 
> 
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fails with tzdata2021e

Marked as reviewed by iris (Reviewer).

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

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

From erikj at openjdk.java.net  Fri Oct 29 16:13:13 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 29 Oct 2021 16:13:13 GMT
Subject: <i18n dev> RFR: 8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
References: <muhmlzqPZjMrf-U_ku9s8mr8Vyn1z5yCabwWvbHvDa8=.a670b30e-3f55-47db-9ba1-d351ee8ed6c9@github.com>
Message-ID: <JiIwHg9uscZJd2oo2RYFXJBTN06hDaVGQGYj_MikwHA=.6baac9c8-95fb-429e-8960-ba7396d1d5c8@github.com>

On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review the integration of tzdata2021e (including tzdata2021d) to the JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests. 
> 
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fails with tzdata2021e

Marked as reviewed by erikj (Reviewer).

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

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