From serb at openjdk.java.net  Fri Oct  1 01:39:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 01:39:31 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <dkln0dazIDjEGd1PL0SoapfuomyHQqBuLx6Amig4oSo=.7735abe3-0eb7-4be7-a4a8-ed18c143b5ed@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@github.com>
 <WrLMxgK_mhps4eR32AkXwCWfqHvwBIPki_aJZbspsrg=.6956c860-f68f-4ab9-80e1-44d795ecc7be@github.com>
 <-6m-FQLBb9SgouaBObjGmNW0eukggujk_gVgqxv4Nmc=.c3887d22-1163-48e5-8d74-a870770abd39@github.com>
 <6Xtrgr_XaaB4_i80BPEbX2AnT6QFE16kmEGMHyIn9lA=.336d6708-9709-41cd-88c4-69975899f8bf@github.com>
 <dkln0dazIDjEGd1PL0SoapfuomyHQqBuLx6Amig4oSo=.7735abe3-0eb7-4be7-a4a8-ed18c143b5ed@github.com>
Message-ID: <ZsGotl_xdRtbDPIboyVjz5oHvOVcm-NKF3Bz3Eo_JAc=.96c8b569-0785-4af7-9f27-635d1e6434d7@github.com>

On Sat, 25 Sep 2021 12:10:16 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Shall we also fix ToolBasicTest.java and ToolSimpleTest.java just as what is done for LambdaTranslationTest1.java and LambdaTranslationTest2.java? If so, the 4 tests would be also fixed on our MacOS platforms.

I do not want to add a global locale parameter to the places which may trigger loading of the different translations.
Probably we missed the bugs like this(not exactly but similar to) https://bugs.openjdk.java.net/browse/JDK-8274544 because everybody passes US locale to the tests. Probably we missed some other bugs as well.

> And do you test the fix on Linux? Thanks.

On Linux  I have checked "JA" and "RU" locales, nothing changed for "JA" it uses the same float format as the US, so the LambdaTranslationTest1/LambdaTranslationTest2 passed before/after the fix and the ToolBasicTest/ToolSimpleTest failed in the "JA" locale, one of the subtests compare the expected output saved for US locale with the real output of the test.

For RU locale the tests fail before the fix and passed after because there is no specific translation so the US text is used, and this PR fixes the problem in the float format.

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

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

From jiefu at openjdk.java.net  Fri Oct  1 01:46:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 1 Oct 2021 01:46:41 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <Bg_0OEnVc6NQc_wRKSVUvnCNwK-W_DmkJ_SWI6cPgf8=.49c54992-6349-4c54-9184-66e54b1c9847@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

So this change doesn't fix the failure with Chinese and JA locales.

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

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

From serb at openjdk.java.net  Fri Oct  1 01:53:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 01:53:31 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <Bg_0OEnVc6NQc_wRKSVUvnCNwK-W_DmkJ_SWI6cPgf8=.49c54992-6349-4c54-9184-66e54b1c9847@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <Bg_0OEnVc6NQc_wRKSVUvnCNwK-W_DmkJ_SWI6cPgf8=.49c54992-6349-4c54-9184-66e54b1c9847@github.com>
Message-ID: <owuMMARwGr-ZOlnddIK6x5mODv5T1L1tJLzA3VkEgdg=.78f7ce5a-cbf3-4850-82c8-208e33138100@github.com>

On Fri, 1 Oct 2021 01:43:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> So this change doesn't fix the failure with Chinese and JA locales.

Yes, I can rephrase it as "it fixes the locales which do not have translations".

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

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

From jiefu at openjdk.java.net  Fri Oct  1 01:57:45 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 1 Oct 2021 01:57:45 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <owuMMARwGr-ZOlnddIK6x5mODv5T1L1tJLzA3VkEgdg=.78f7ce5a-cbf3-4850-82c8-208e33138100@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <Bg_0OEnVc6NQc_wRKSVUvnCNwK-W_DmkJ_SWI6cPgf8=.49c54992-6349-4c54-9184-66e54b1c9847@github.com>
 <owuMMARwGr-ZOlnddIK6x5mODv5T1L1tJLzA3VkEgdg=.78f7ce5a-cbf3-4850-82c8-208e33138100@github.com>
Message-ID: <olsJxVFYGJMc2t-RcQ_NVad6KQ28-noOpuxLDQBSoUY=.a40e633c-a9e0-4bf7-94b2-9ae4eb248e9d@github.com>

On Fri, 1 Oct 2021 01:50:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > So this change doesn't fix the failure with Chinese and JA locales.
> 
> Yes, I can rephrase it as "it fixes the locales which do not have translations".

Then people with RU locale should look at this fix.

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

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

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: 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 serb at openjdk.java.net  Fri Oct  1 04:10:29 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 1 Oct 2021 04:10:29 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <K1DeRgqoBgKwTHRB1EpI7O3HYNeuurDZWhBfbdcfJ8k=.87ed331b-ad2e-4d5a-a2b0-027c3e56f882@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

@aivanov-jdk please take a look

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

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

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: 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: 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: 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: 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 clanger at openjdk.java.net  Fri Oct  1 13:02:44 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 1 Oct 2021 13:02:44 GMT
Subject: RFR: 8274642: jdk/jshell/CommandCompletionTest.java fails with
 NoSuchElementException after JDK-8271287
Message-ID: <wcoHtWQDcH5iWDC4Iv0obX1N6L2HmeOtrtxi83eQbUU=.4eb7966f-6c14-4a31-8476-db9b081649fc@github.com>

Sometimes user.home might not contain any files that would match CLASSPATH_FILTER. This is a suggestion
to skip the test in this case. I'm open to alternative solutions, though.

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

Commit messages:
 - Fix 8274642

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

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

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: 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 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: 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: 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: 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 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: 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 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: 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 jlahoda at openjdk.java.net  Tue Oct  5 16:12:14 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 5 Oct 2021 16:12:14 GMT
Subject: RFR: 8274642: jdk/jshell/CommandCompletionTest.java fails with
 NoSuchElementException after JDK-8271287
In-Reply-To: <wcoHtWQDcH5iWDC4Iv0obX1N6L2HmeOtrtxi83eQbUU=.4eb7966f-6c14-4a31-8476-db9b081649fc@github.com>
References: <wcoHtWQDcH5iWDC4Iv0obX1N6L2HmeOtrtxi83eQbUU=.4eb7966f-6c14-4a31-8476-db9b081649fc@github.com>
Message-ID: <qnQ2cMJBo_SUvzafJwOBtjJhyfHMHlyXBj7m9w4otm0=.57a37fb4-e785-4ae2-9c05-0aab3d758356@github.com>

On Fri, 1 Oct 2021 12:53:33 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Sometimes user.home might not contain any files that would match CLASSPATH_FILTER. This is a suggestion
> to skip the test in this case. I'm open to alternative solutions, though.

Looks reasonable, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

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

From clanger at openjdk.java.net  Tue Oct  5 21:10:13 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 5 Oct 2021 21:10:13 GMT
Subject: RFR: 8274642: jdk/jshell/CommandCompletionTest.java fails with
 NoSuchElementException after JDK-8271287
In-Reply-To: <wcoHtWQDcH5iWDC4Iv0obX1N6L2HmeOtrtxi83eQbUU=.4eb7966f-6c14-4a31-8476-db9b081649fc@github.com>
References: <wcoHtWQDcH5iWDC4Iv0obX1N6L2HmeOtrtxi83eQbUU=.4eb7966f-6c14-4a31-8476-db9b081649fc@github.com>
Message-ID: <EAXfNTWZmZv077N9i5zZFsv7cKM59lnQYX10DHOYgs8=.b7d4d494-45d9-4f9f-a4ba-4d77c0512722@github.com>

On Fri, 1 Oct 2021 12:53:33 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Sometimes user.home might not contain any files that would match CLASSPATH_FILTER. This is a suggestion
> to skip the test in this case. I'm open to alternative solutions, though.

Thanks for the review.

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

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

From clanger at openjdk.java.net  Tue Oct  5 21:10:15 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 5 Oct 2021 21:10:15 GMT
Subject: Integrated: 8274642: jdk/jshell/CommandCompletionTest.java fails with
 NoSuchElementException after JDK-8271287
In-Reply-To: <wcoHtWQDcH5iWDC4Iv0obX1N6L2HmeOtrtxi83eQbUU=.4eb7966f-6c14-4a31-8476-db9b081649fc@github.com>
References: <wcoHtWQDcH5iWDC4Iv0obX1N6L2HmeOtrtxi83eQbUU=.4eb7966f-6c14-4a31-8476-db9b081649fc@github.com>
Message-ID: <f5MrapZOqF5zwiNhh8g9ywT_uCeBUK-3GZ1Nun2ZlfU=.3fa861aa-c232-452d-8808-c15a394c35e2@github.com>

On Fri, 1 Oct 2021 12:53:33 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Sometimes user.home might not contain any files that would match CLASSPATH_FILTER. This is a suggestion
> to skip the test in this case. I'm open to alternative solutions, though.

This pull request has now been integrated.

Changeset: 47262670
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/47262670f371923a704ec521da40010c2a46be5a
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8274642: jdk/jshell/CommandCompletionTest.java fails with NoSuchElementException after JDK-8271287

Reviewed-by: jlahoda

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

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

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: 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 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: 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: 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: 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 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: 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 18:11:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 6 Oct 2021 18:11:10 GMT
Subject: 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 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: 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: 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 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: 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 sundar at openjdk.java.net  Tue Oct 12 02:38:48 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 12 Oct 2021 02:38:48 GMT
Subject: RFR: 8273682: Upgrade Jline to 3.20.0
In-Reply-To: <UJAKTvBt-_qI2VFMYUTut4X1NXFsaH_LFIeIxm7oheM=.a5a3950e-bdf3-4368-b470-b374400d9a89@github.com>
References: <UJAKTvBt-_qI2VFMYUTut4X1NXFsaH_LFIeIxm7oheM=.a5a3950e-bdf3-4368-b470-b374400d9a89@github.com>
Message-ID: <YExHVmMKuGtEy3mPfTzaZz11QnAjz1Tb5CcPeR01OLk=.fd793db7-7514-40c8-923b-380650eab226@github.com>

On Thu, 23 Sep 2021 14:43:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed.
> 
> Thanks!

LGTM

src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/CompletionMatcher.java line 32:

> 30:      *
> 31:      * @param candidates list of candidates
> 32:      * @return a map of candidates that completion matcher matches

a list of ..?

src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/EndOfFileException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2002-2020, the original author or authors.

2021

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

Marked as reviewed by sundar (Reviewer).

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

From jlahoda at openjdk.java.net  Tue Oct 12 17:41:57 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 12 Oct 2021 17:41:57 GMT
Subject: RFR: 8273682: Upgrade Jline to 3.20.0
In-Reply-To: <YExHVmMKuGtEy3mPfTzaZz11QnAjz1Tb5CcPeR01OLk=.fd793db7-7514-40c8-923b-380650eab226@github.com>
References: <UJAKTvBt-_qI2VFMYUTut4X1NXFsaH_LFIeIxm7oheM=.a5a3950e-bdf3-4368-b470-b374400d9a89@github.com>
 <YExHVmMKuGtEy3mPfTzaZz11QnAjz1Tb5CcPeR01OLk=.fd793db7-7514-40c8-923b-380650eab226@github.com>
Message-ID: <wo-W26tcKyTUOKLwkq0LI0ukanyYEIoMZtUsqL9ao-w=.e6749d2d-66bc-44e0-adce-cc7e9e21f8ae@github.com>

On Thu, 23 Sep 2021 15:43:08 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed.
>> 
>> Thanks!
>
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/CompletionMatcher.java line 32:
> 
>> 30:      *
>> 31:      * @param candidates list of candidates
>> 32:      * @return a map of candidates that completion matcher matches
> 
> a list of ..?

Thanks, I've filled:
https://github.com/jline/jline3/issues/711

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

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

From jlahoda at openjdk.java.net  Wed Oct 13 07:00:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 13 Oct 2021 07:00:10 GMT
Subject: RFR: 8273039: JShell crashes when naming variable or method "abstract"
 or "strictfp"
Message-ID: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>

When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines:

package REPL;
import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*;
class $JShell$DOESNOTMATTER {
    public static Object do_it$() throws Throwable {
        return int strictfp = 0;
    }
}


This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers.

The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation.

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

Commit messages:
 - Removing trailing whitespace
 - 8273039: JShell crashes when naming variable or method "abstract" or "strictfp"

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

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

From jlahoda at openjdk.java.net  Wed Oct 13 10:18:57 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 13 Oct 2021 10:18:57 GMT
Subject: Integrated: 8273682: Upgrade Jline to 3.20.0
In-Reply-To: <UJAKTvBt-_qI2VFMYUTut4X1NXFsaH_LFIeIxm7oheM=.a5a3950e-bdf3-4368-b470-b374400d9a89@github.com>
References: <UJAKTvBt-_qI2VFMYUTut4X1NXFsaH_LFIeIxm7oheM=.a5a3950e-bdf3-4368-b470-b374400d9a89@github.com>
Message-ID: <QkoX573UPTQ2P3caw_U1KfQLNaPaAdJqDwevrodh-WE=.79dea4ee-83bd-4541-afb6-64b76ad1ea31@github.com>

On Thu, 23 Sep 2021 14:43:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I'd like to upgrade the internal JLine to 3.20.0, to support the rxvt terminal (see JDK-8270943), and to generally use a newer version of the library. This patch is basically a application of relevant parts of the diff between JLine 3.14.0 and 3.20.0, with merge fixes as needed.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b8cb76ad
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b8cb76ad210cb3e7524c7f5b13cfe57746ac05d4
Stats:     2667 lines in 47 files changed: 1830 ins; 473 del; 364 mod

8273682: Upgrade Jline to 3.20.0

Reviewed-by: sundar

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

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

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: 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  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: 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 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: 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: 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: 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 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: 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 jlahoda at openjdk.java.net  Fri Oct 22 11:05:28 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 22 Oct 2021 11:05:28 GMT
Subject: RFR: 8274734: the method jdk.jshell.SourceCodeAnalysis documentation
 not working
Message-ID: <EnV8EAKUDeOJo6XOjYleweR0rYEEyfKsoZyrBKnyW7Q=.35757640-ac39-4a19-a9de-e3c623766a74@github.com>

The `SourceCodeAnalysisImpl` needs to open `src.zip` to read the sources to get javadoc. Unfortunately, it uses the variant of the `newFileSystem` method that can only be used one, and hence only one `SourceCodeAnalysisImpl` can provide documentation. The proposed solution is to use the variant of the `newFileSystem` method that can open the FileSystem multiple times, so that multiple independent SourceCodeAnalysisImpl instances can provide documentation.

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

Commit messages:
 - 8274734: the method jdk.jshell.SourceCodeAnalysis documentation not working

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

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

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: 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: 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 duke at openjdk.java.net  Fri Oct 29 05:29:16 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 29 Oct 2021 05:29:16 GMT
Subject: Withdrawn: 8268725: jshell does not support the --enable-native-access
 option
In-Reply-To: <ltD_VTZvtHBNd3erUrE39dTc2EAHXlCPG4OGTsUnWOo=.126fd3c6-fd4a-4671-a8e3-9b6d5dd3dbb5@github.com>
References: <ltD_VTZvtHBNd3erUrE39dTc2EAHXlCPG4OGTsUnWOo=.126fd3c6-fd4a-4671-a8e3-9b6d5dd3dbb5@github.com>
Message-ID: <FC2LVQsdr1-aqDI62tfaPe6DxX0fljk1bBCsp95dZw0=.cc8b8007-0322-4d6c-88c1-8a4258c4868f@github.com>

On Fri, 16 Jul 2021 12:26:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adding `--enable-native-access` option to JShell. Set as a parameter to the remote agent (`--enable-native-access=ALL-UNNAMED`), but not the compiler, as the compiler does not have this option.

This pull request has been closed without being integrated.

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

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

From serb at openjdk.java.net  Fri Oct 29 05:53:13 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Oct 2021 05:53:13 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other locales
 than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <aunQvii8r7sGKnLqrE40QPg-N2gS3eff6it0dUgQH5c=.e0f4707a-da23-474a-bfbb-4f5ee45358c7@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

@aivanov-jdk Alexey do you have any comments or suggestions?

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

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

From aivanov at openjdk.java.net  Fri Oct 29 10:47:13 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 29 Oct 2021 10:47:13 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other locales
 than the US
In-Reply-To: <aunQvii8r7sGKnLqrE40QPg-N2gS3eff6it0dUgQH5c=.e0f4707a-da23-474a-bfbb-4f5ee45358c7@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <aunQvii8r7sGKnLqrE40QPg-N2gS3eff6it0dUgQH5c=.e0f4707a-da23-474a-bfbb-4f5ee45358c7@github.com>
Message-ID: <fFZTTODQAW7MhV5i3H2QPSsWZ3tqbW5WXJN6yaqpaqo=.7b036236-4b8f-4e30-b9c1-6b15131b843b@github.com>

On Fri, 29 Oct 2021 05:50:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> @aivanov-jdk Alexey do you have any comments or suggestions?

Sorry for my delayed reply. I have never used Russian locale when working with JDK, if I remember correctly, I even experienced JDK build failures with Russian locale.

To me, the change looks good: it makes the tests more stable, these updated tests should pass even if the current locale is different than the US. I believe it's a common practice, as it's mentioned in [Testing the JDK](https://openjdk.java.net/groups/build/doc/testing.html#non-us-locale):

> If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US.

However, I haven't tried running the tests under Russian or French locale yet.

As for translations, I believe the tests which specifically verify translations should also set the locale explicitly and check the expected output.

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

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