From jlahoda at openjdk.java.net  Thu Sep  2 10:42:41 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 2 Sep 2021 10:42:41 GMT
Subject: RFR: 8273257: jshell doesn't compile a sealed hierarchy with a sealed
 interface and a non-sealed leaf
Message-ID: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>

Considering code like:

non-sealed class C implements Undefined {}


javac will currently produce these compile-time errors:

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

Commit messages:
 - 8273257: jshell doesnt compile a sealed hierarchy with a sealed interface and a non-sealed leaf

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

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

From jlahoda at openjdk.java.net  Thu Sep  2 13:10:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 2 Sep 2021 13:10:32 GMT
Subject: RFR: 8268725: jshell does not support the --enable-native-access
 option [v2]
In-Reply-To: <l7lH19zqQHtM8y2kff4ZDtuG48Ie2-bybdCf4sH5FkI=.669e35ce-a9d6-49e3-ae34-0753ca39beec@github.com>
References: <ltD_VTZvtHBNd3erUrE39dTc2EAHXlCPG4OGTsUnWOo=.126fd3c6-fd4a-4671-a8e3-9b6d5dd3dbb5@github.com>
 <l7lH19zqQHtM8y2kff4ZDtuG48Ie2-bybdCf4sH5FkI=.669e35ce-a9d6-49e3-ae34-0753ca39beec@github.com>
Message-ID: <7jaG4eDx7hwWeQCuUEk9xGJzncmS82GocBvLc1k83ek=.201cf1e8-0775-410c-8386-d67d8f8da77a@github.com>

On Fri, 16 Jul 2021 18:06:27 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.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Including --enable-native-access in help

I've written a CSR here:
https://bugs.openjdk.java.net/browse/JDK-8273281

Would it be possible to get feedback on it? Thanks!

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

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

From forax at openjdk.java.net  Thu Sep  2 13:47:38 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 2 Sep 2021 13:47:38 GMT
Subject: RFR: 8268725: jshell does not support the --enable-native-access
 option [v2]
In-Reply-To: <l7lH19zqQHtM8y2kff4ZDtuG48Ie2-bybdCf4sH5FkI=.669e35ce-a9d6-49e3-ae34-0753ca39beec@github.com>
References: <ltD_VTZvtHBNd3erUrE39dTc2EAHXlCPG4OGTsUnWOo=.126fd3c6-fd4a-4671-a8e3-9b6d5dd3dbb5@github.com>
 <l7lH19zqQHtM8y2kff4ZDtuG48Ie2-bybdCf4sH5FkI=.669e35ce-a9d6-49e3-ae34-0753ca39beec@github.com>
Message-ID: <BfeHoMf0KZGMsOP8_HFw1HulIkNC1rRFoNMzPMvAdbs=.a1efd43e-9b39-42d5-b74e-9c740dd7bbc6@github.com>

On Fri, 16 Jul 2021 18:06:27 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.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Including --enable-native-access in help

I don't like the fact that --enable-native-access will behave differently with java and jshell,
in fact, it's worst, for jshell, --enable-native-access and -R--enable-native-access will behave differently.

For me, either "--enable-native-access" is a valid syntax and in case both  java and jshell should support it,
or the shortcut to use the unnamed module does not worth the cost and in that case, it should not be implemented.

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

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

From jlahoda at openjdk.java.net  Thu Sep  2 14:24:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 2 Sep 2021 14:24:10 GMT
Subject: RFR: 8268725: jshell does not support the --enable-native-access
 option [v2]
In-Reply-To: <BfeHoMf0KZGMsOP8_HFw1HulIkNC1rRFoNMzPMvAdbs=.a1efd43e-9b39-42d5-b74e-9c740dd7bbc6@github.com>
References: <ltD_VTZvtHBNd3erUrE39dTc2EAHXlCPG4OGTsUnWOo=.126fd3c6-fd4a-4671-a8e3-9b6d5dd3dbb5@github.com>
 <l7lH19zqQHtM8y2kff4ZDtuG48Ie2-bybdCf4sH5FkI=.669e35ce-a9d6-49e3-ae34-0753ca39beec@github.com>
 <BfeHoMf0KZGMsOP8_HFw1HulIkNC1rRFoNMzPMvAdbs=.a1efd43e-9b39-42d5-b74e-9c740dd7bbc6@github.com>
Message-ID: <oFsNia4OLaQ5Qp2iX2pH7WlP4Qs7r9G-y9ehhauas4o=.f2040fc8-3bc5-4b8b-ba56-3325295462f3@github.com>

On Thu, 2 Sep 2021 13:44:26 GMT, R?mi Forax <forax at openjdk.org> wrote:

> I don't like the fact that --enable-native-access will behave differently with java and jshell,
> in fact, it's worst, for jshell, --enable-native-access and -R--enable-native-access will behave differently.
> 
> For me, either "--enable-native-access" is a valid syntax and in case both java and jshell should support it,
> or the shortcut to use the unnamed module does not worth the cost and in that case, it should not be implemented.

I was struggling with that a bit also. But, in general, I don't think JShell says/advertises the snippets run in an unnamed module. So, requiring this knowledge from the user does not seem right, and would not be a big help over the currently working `-R--enable-preview=ALL-UNNAMED`. Also, the (existing) `--add-exports` option in JShell also does not accept the target module, only the source module and package. And `--enable-preview` also works slightly differently in runtime/JShell and at compile time. So there are already differences between options, and while it is not particularly nice to have another difference, it does not seem so bad to me.

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

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

From vromero at openjdk.java.net  Thu Sep  2 17:09:02 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 2 Sep 2021 17:09:02 GMT
Subject: RFR: 8273257: jshell doesn't compile a sealed hierarchy with a
 sealed interface and a non-sealed leaf
In-Reply-To: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>
References: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>
Message-ID: <mVudR2g1Ecou_rd4jI8LrRyPF2WX9yDIIcYkbSbsCSk=.0b39fdd4-8c77-4397-8967-863780f6469b@github.com>

On Thu, 2 Sep 2021 10:34:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> non-sealed class C implements Undefined {}
> 
> 
> javac will currently produce these compile-time errors:

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From forax at openjdk.java.net  Thu Sep  2 17:30:13 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 2 Sep 2021 17:30:13 GMT
Subject: RFR: 8268725: jshell does not support the --enable-native-access
 option [v2]
In-Reply-To: <l7lH19zqQHtM8y2kff4ZDtuG48Ie2-bybdCf4sH5FkI=.669e35ce-a9d6-49e3-ae34-0753ca39beec@github.com>
References: <ltD_VTZvtHBNd3erUrE39dTc2EAHXlCPG4OGTsUnWOo=.126fd3c6-fd4a-4671-a8e3-9b6d5dd3dbb5@github.com>
 <l7lH19zqQHtM8y2kff4ZDtuG48Ie2-bybdCf4sH5FkI=.669e35ce-a9d6-49e3-ae34-0753ca39beec@github.com>
Message-ID: <XmHsZQ4SYWOkiB95gNTb_6n-xoADI8Kx6Zz9HaVi5h4=.784d9ac5-ce56-4410-b60d-28cbbddf0523@github.com>

On Fri, 16 Jul 2021 18:06:27 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.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Including --enable-native-access in help

For me, the code that can require enable-native-access can be either a code written in jshell or a library/module used by the code written by jshell.
Having '-R--enable-preview=ALL-UNNAMED' will only cover the former use case not the later.

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

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

From serb at openjdk.java.net  Thu Sep  2 22:59:31 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 2 Sep 2021 22:59:31 GMT
Subject: Integrated: 8272805: Avoid looking up standard charsets
In-Reply-To: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
References: <No76RQeNc8gaZZ3GXCT-g0gJz3WfSYxhKws39w4xMoE=.6e450cbf-6c4d-423f-8c6f-4c5a2dfbb940@github.com>
Message-ID: <tin2l2VOVGWktdXefgDZIBJz2kpyYBxoc4d9Tq2Qzdk=.f818542a-aba3-400c-9127-74516d3d0905@github.com>

On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
> 
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
> 
> This could be done more efficiently(up to x20 time faster) with use of java.nio.charset.StandardCharsets:
> absolutePath.getBytes(StandardCharsets.UTF_8);
> 
> The later variant also makes the code cleaner, as it is known not to throw UnsupportedEncodingException in contrary to the former variant.
> 
> This change includes:
>  * demo/utils
>  * jdk.xx packages
>  * Some places were missed in the previous changes. I have found it by tracing the calls to the Charset.forName() by executing tier1,2,3 and desktop tests.
> 
> Some performance discussion: https://github.com/openjdk/jdk/pull/5063
> 
> Code excluded in this fix: the Xerces library(should be fixed upstream), J2DBench(should be compatible to 1.4), some code in the network(the change there are not straightforward, will do it later).
> 
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.

This pull request has now been integrated.

Changeset: 7fff22af
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7fff22afe711c8c04dbf4cf5b4938d40632e4987
Stats:     364 lines in 53 files changed: 98 ins; 128 del; 138 mod

8272805: Avoid looking up standard charsets

Reviewed-by: weijun, naoto, dfuchs, azvegint, erikj

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

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

From jlahoda at openjdk.java.net  Fri Sep  3 09:34:32 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Sep 2021 09:34:32 GMT
Subject: Integrated: 8273257: jshell doesn't compile a sealed hierarchy with a
 sealed interface and a non-sealed leaf
In-Reply-To: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>
References: <bu1alAmsA5fiMzr_NFHSu-Yx5B06FPdOb8lhniivDd8=.2bfac842-cc8a-4366-abaa-56b51f710310@github.com>
Message-ID: <LTddO_fgwqrGeF0QQXU4iew1Eg3n0ajYazpcadhHNRc=.5fd1ea20-d191-476f-9303-289fbe5435d7@github.com>

On Thu, 2 Sep 2021 10:34:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Considering code like:
> 
> non-sealed class C implements Undefined {}
> 
> 
> javac will currently produce these compile-time errors:

This pull request has now been integrated.

Changeset: 7b023a3f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b023a3f607f44da1b13bc9d2884a5f13723d524
Stats:     45 lines in 3 files changed: 40 ins; 0 del; 5 mod

8273257: jshell doesn't compile a sealed hierarchy with a sealed interface and a non-sealed leaf

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Tue Sep  7 09:53:41 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 7 Sep 2021 09:53:41 GMT
Subject: Integrated: 8272135: jshell: Method cannot use its overloaded version
In-Reply-To: <ZsSyUI5k5vXFj6y0ZXEzc9RfhfRnoqapMK7sps_Q1Fo=.20148dc6-0f92-49a7-b9f0-78a6dabc5b81@github.com>
References: <ZsSyUI5k5vXFj6y0ZXEzc9RfhfRnoqapMK7sps_Q1Fo=.20148dc6-0f92-49a7-b9f0-78a6dabc5b81@github.com>
Message-ID: <7r6a_h5mZsryAbmmNbOKuR5qE9UvfR3NZScz5XD4v2U=.aef13482-25d8-469b-9658-30047131f434@github.com>

On Fri, 13 Aug 2021 15:20:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider separate snippets like:
> 
> int m(int i) { return 1; }
> 
> and:
> 
> int m(String s) { return m(0); }
> 
> 
> If these are independent snippets, JShell will currently compile first the first snippet (say into class called `A`), and then the second snippet. The actual code for the second snippet will be in this direction:
> 
> import static A.m;
> public class B {
>     int m(String s) { return m(0); }
> }
> 
> 
> Note that here the method resolution, when seeing method name `m`, will not see the `m(int)` method at all, as the lookup will stop on the current class' method called `m` and will never proceed to look at the `m` method from the first snippet/class `A`.
> 
> JShell generally tries to coalescence processing of overloading methods (in the `Unit.setWrap` method), but the overloaded methods must be together part of the input, which is not the case in the above example.
> 
> The proposed solution is to detect the possibility of the above situation (call of a method that has the same name as the current snippet's method), and add all same-named overloads to the processing set.

This pull request has now been integrated.

Changeset: 70157c78
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70157c78a838126bb29c91a410d9158763bfa2ad
Stats:     108 lines in 4 files changed: 89 ins; 0 del; 19 mod

8272135: jshell: Method cannot use its overloaded version

Reviewed-by: vromero

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

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

From vromero at openjdk.java.net  Mon Sep 20 15:19:58 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 20 Sep 2021 15:19:58 GMT
Subject: RFR: 8271287: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected"
In-Reply-To: <pxf2RaWZ2I-5JQjBbb8y4elVMzw0Eq-ip6oKUt7lnQE=.786df0c8-a8b9-479e-8acd-00c0e27243c9@github.com>
References: <pxf2RaWZ2I-5JQjBbb8y4elVMzw0Eq-ip6oKUt7lnQE=.786df0c8-a8b9-479e-8acd-00c0e27243c9@github.com>
Message-ID: <ac_rhvRNYvykBhTnAutxYI3VoEOVWerMWNBVAB3Sy_I=.1e286579-1683-4642-86ea-d1ba6b00867e@github.com>

On Tue, 31 Aug 2021 13:48:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell has a test that verifies the file completion understands `~` is a home directory, by testing the completions after:

seems like a good trade-off

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

Marked as reviewed by vromero (Reviewer).

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

From jlahoda at openjdk.java.net  Tue Sep 21 11:14:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 21 Sep 2021 11:14:06 GMT
Subject: RFR: 8270139: jshell InternalError crash for import of @Repeatable
 followed by unresolved ref
Message-ID: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>

For code like:

import java.lang.annotation.Repeatable;
@Repeatable(TestContainer.class)
@interface Test { int value(); }


javac crashes like this:

$ javac -XDdev /tmp/Test.java

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

Commit messages:
 - 8270139: jshell InternalError crash for import of @Repeatable followed by unresolved ref

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

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

From vromero at openjdk.java.net  Tue Sep 21 16:42:34 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 21 Sep 2021 16:42:34 GMT
Subject: RFR: 8270139: jshell InternalError crash for import of
 @Repeatable followed by unresolved ref
In-Reply-To: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>
References: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>
Message-ID: <t4jahqAbnjfuJGLKGqaL5g_DD0cF0taPk00jocZXzzo=.0e1a71b2-7dca-4c13-a7df-9d5bf3f2377b@github.com>

On Tue, 21 Sep 2021 11:05:45 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> import java.lang.annotation.Repeatable;
> @Repeatable(TestContainer.class)
> @interface Test { int value(); }
> 
> 
> javac crashes like this:
> 
> $ javac -XDdev /tmp/Test.java

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

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

From jlahoda at openjdk.java.net  Wed Sep 22 12:56:00 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 22 Sep 2021 12:56:00 GMT
Subject: Integrated: 8270139: jshell InternalError crash for import of
 @Repeatable followed by unresolved ref
In-Reply-To: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>
References: <s-II3KkW7-aANiQETK3UEytZj7QoFBgr6odAfzu7wjc=.f0b97c59-892b-4de6-9377-7a35d11fcfb7@github.com>
Message-ID: <k_ErGIiidQRYSg2xA92daRYGGA088ZX0qqjl_EykFhk=.c51a6716-c1d3-41aa-9fdf-d93d0bbf48be@github.com>

On Tue, 21 Sep 2021 11:05:45 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like:
> 
> import java.lang.annotation.Repeatable;
> @Repeatable(TestContainer.class)
> @interface Test { int value(); }
> 
> 
> javac crashes like this:
> 
> $ javac -XDdev /tmp/Test.java

This pull request has now been integrated.

Changeset: ba7d550c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ba7d550c6e6d84b36d81aafa1dfded0c99b5c248
Stats:     169 lines in 3 files changed: 168 ins; 0 del; 1 mod

8270139: jshell InternalError crash for import of @Repeatable followed by unresolved ref

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Wed Sep 22 12:57:06 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 22 Sep 2021 12:57:06 GMT
Subject: Integrated: 8271287: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected"
In-Reply-To: <pxf2RaWZ2I-5JQjBbb8y4elVMzw0Eq-ip6oKUt7lnQE=.786df0c8-a8b9-479e-8acd-00c0e27243c9@github.com>
References: <pxf2RaWZ2I-5JQjBbb8y4elVMzw0Eq-ip6oKUt7lnQE=.786df0c8-a8b9-479e-8acd-00c0e27243c9@github.com>
Message-ID: <phIqRkAev5aTlDVtg9r59aFE835zrLfvFB1cyhgZuHA=.4960f4bb-6f97-4b61-8308-754f6edcd5b8@github.com>

On Tue, 31 Aug 2021 13:48:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell has a test that verifies the file completion understands `~` is a home directory, by testing the completions after:

This pull request has now been integrated.

Changeset: 71788c69
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/71788c69dbae854331f3393044dab458c906045f
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8271287: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected"

Reviewed-by: vromero

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

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

From jlahoda at openjdk.java.net  Thu Sep 23 15:38:44 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 23 Sep 2021 15:38:44 GMT
Subject: RFR: 8273682: Upgrade Jline to 3.20.0
Message-ID: <UJAKTvBt-_qI2VFMYUTut4X1NXFsaH_LFIeIxm7oheM=.a5a3950e-bdf3-4368-b470-b374400d9a89@github.com>

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!

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

Commit messages:
 - Removing trailing whitespace.
 - Fixing tests.
 - Fixing Windows build.
 - Upgrading JLine to 3.20.0

Changes: https://git.openjdk.java.net/jdk/pull/5655/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5655&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273682
  Stats: 2667 lines in 47 files changed: 1830 ins; 473 del; 364 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5655.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5655/head:pull/5655

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

From jiefu at openjdk.java.net  Sat Sep 25 02:43:56 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 02:43:56 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: <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@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).

There are still 1500+ failures due to non-US locale after this patch.

So my question is: does it make sense to fix only 4 of them?
Thanks.

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

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

From serb at openjdk.java.net  Sat Sep 25 03:13:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 03:13:48 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: <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@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).

These are the only tests reported in Fr and Ru locales in t1/t2/t3. Are you sure that 1500 failures are caused by the tests issues and not a problem in JDK?

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

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

From jiefu at openjdk.java.net  Sat Sep 25 03:26:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 03:26:53 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>
Message-ID: <dLH6tzkd2Q3kUn7db21uw8S3bVwTWmkIHi8H3cRp3sI=.db58a312-0a7c-4c07-a62b-580d7a184636@github.com>

On Sat, 25 Sep 2021 03:10:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> These are the only tests reported in Fr and Ru locales in t1/t2/t3. Are you sure that 1500 failures are caused by the tests issues and not a problem in JDK?

If I test with `JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"`, most of the failures would disappear.

make test  TEST="tier1 tier2 tier3" with your patch

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:test/hotspot/jtreg:tier1                     1810  1809     1     0 <<
>> jtreg:test/jdk:tier1                               2069  2065     4     0 <<
>> jtreg:test/langtools:tier1                         4238  2643  1593     2 <<
   jtreg:test/jaxp:tier1                                 0     0     0     0
   jtreg:test/lib-test:tier1                             0     0     0     0
   jtreg:test/hotspot/jtreg:tier2                      444   444     0     0
>> jtreg:test/jdk:tier2                               3765  3727    38     0 <<
>> jtreg:test/langtools:tier2                           12    10     2     0 <<
>> jtreg:test/jaxp:tier2                               452   449     3     0 <<
   jtreg:test/hotspot/jtreg:tier3                       85    85     0     0
   jtreg:test/jdk:tier3                                174   174     0     0
   jtreg:test/langtools:tier3                            0     0     0     0
   jtreg:test/jaxp:tier3                                 0     0     0     0
==============================
TEST FAILURE


------

make test JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" TEST="tier1 tier2 tier3" with your patch

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:test/hotspot/jtreg:tier1                     1810  1809     1     0 <<
   jtreg:test/jdk:tier1                               2069  2069     0     0
>> jtreg:test/langtools:tier1                         4238  4230     8     0 <<
   jtreg:test/jaxp:tier1                                 0     0     0     0
   jtreg:test/lib-test:tier1                             0     0     0     0
   jtreg:test/hotspot/jtreg:tier2                      444   444     0     0
>> jtreg:test/jdk:tier2                               3765  3747    18     0 <<
   jtreg:test/langtools:tier2                           12    12     0     0
>> jtreg:test/jaxp:tier2                               452   451     1     0 <<
   jtreg:test/hotspot/jtreg:tier3                       85    85     0     0   
   jtreg:test/jdk:tier3                                174   174     0     0
   jtreg:test/langtools:tier3                            0     0     0     0
   jtreg:test/jaxp:tier3                                 0     0     0     0
==============================
TEST FAILURE

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

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

From serb at openjdk.java.net  Sat Sep 25 03:40:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 03:40:56 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <dLH6tzkd2Q3kUn7db21uw8S3bVwTWmkIHi8H3cRp3sI=.db58a312-0a7c-4c07-a62b-580d7a184636@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>
 <dLH6tzkd2Q3kUn7db21uw8S3bVwTWmkIHi8H3cRp3sI=.db58a312-0a7c-4c07-a62b-580d7a184636@github.com>
Message-ID: <2xQ3i6O5Q6NPZ2IQYfidFza31R9U4MyTwmC9qyY9OR4=.3949819c-e49f-4f32-addf-5f1d06c2d8c8@github.com>

On Sat, 25 Sep 2021 03:23:37 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> If I test with `JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"`, most of the failures would disappear.

If the failure disappeared if the "user.language=en" is used does not mean that this is not a JDK bug or some other bugs in the tests. What is the reason for the falure?

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

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

From jiefu at openjdk.java.net  Sat Sep 25 03:52:00 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 03:52:00 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <2xQ3i6O5Q6NPZ2IQYfidFza31R9U4MyTwmC9qyY9OR4=.3949819c-e49f-4f32-addf-5f1d06c2d8c8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
 <GDE-7TCHcqni6213tvvGvneVNhTt3xwktNOJV9SfmPQ=.9438dc06-46fd-4034-8645-816119b31202@github.com>
 <dLH6tzkd2Q3kUn7db21uw8S3bVwTWmkIHi8H3cRp3sI=.db58a312-0a7c-4c07-a62b-580d7a184636@github.com>
 <2xQ3i6O5Q6NPZ2IQYfidFza31R9U4MyTwmC9qyY9OR4=.3949819c-e49f-4f32-addf-5f1d06c2d8c8@github.com>
Message-ID: <lOpDEph8HRdNIUpcX6d65fjSS77RaaK6C4Zrl3g3hlk=.d7290a62-a404-44cb-ad54-f45ed12b1246@github.com>

On Sat, 25 Sep 2021 03:38:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > If I test with `JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"`, most of the failures would disappear.
> 
> If the failure disappeared if the "user.language=en" is used does not mean that this is not a JDK bug or some other bugs in the tests. What is the reason for the falure?

An important reason is that the expected output doesn't match due to different languages.

 STDERR:
  stdout: [];
  stderr: [??: ?? emptynumbootstrapmethods1 ???? main ??, ?? main ?????:
    public static void main(String[] args) 
 ?? JavaFX ?????????javafx.application.Application
 ]
  exitValue = 1
 
 java.lang.RuntimeException: 'Main method not found in class emptynumbootstrapmethods1' missing from stdout/stderr 
 
        at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221)
        at TestEmptyBootstrapMethodsAttr.main(TestEmptyBootstrapMethodsAttr.java:56)
        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.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
        at java.base/java.lang.Thread.run(Thread.java:833)
 
 JavaTest Message: Test threw exception: java.lang.RuntimeException
 JavaTest Message: shutting down test
 
 
 TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'Main method not found in class emptynumbootstrapmethods1' missing from stdout/stderr


E.g., Test runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java with the locale:

LANG=en_US.UTF-8 \
LC_ALL=C \

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

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

From serb at openjdk.java.net  Sat Sep 25 05:16:59 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 05:16:59 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <FK-Tn5YDrSZZSR1_dL6txjPj_8GtRAan5S0X81fu9xI=.855d0006-df99-44d9-8ec9-139753386382@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>
Message-ID: <WrLMxgK_mhps4eR32AkXwCWfqHvwBIPki_aJZbspsrg=.6956c860-f68f-4ab9-80e1-44d795ecc7be@github.com>

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

> There are still 1500+ failures due to non-US locale after this patch.
> 
> So my question is: does it make sense to fix only 4 of them?

This error means that your OpenJDK build contains the translation for your locale, and different tools use the resource bundles to translate different outputs. Looks like nobody validates that the translated output is correct for the various cases since the tests fail on non-US translated locales. I guess in the ideal world that tests should be updated to validate the output for each locale, or probably even better they should check that the output is correct for some specific "key" in the resource bundle.

The current issue is different, it fixes the tests depended on some specific float format and has no dependency on the resource bundles.

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

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

From jiefu at openjdk.java.net  Sat Sep 25 07:41:54 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 07:41:54 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <WrLMxgK_mhps4eR32AkXwCWfqHvwBIPki_aJZbspsrg=.6956c860-f68f-4ab9-80e1-44d795ecc7be@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>
Message-ID: <-6m-FQLBb9SgouaBObjGmNW0eukggujk_gVgqxv4Nmc=.c3887d22-1163-48e5-8d74-a870770abd39@github.com>

On Sat, 25 Sep 2021 05:13:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > There are still 1500+ failures due to non-US locale after this patch.
> > So my question is: does it make sense to fix only 4 of them?
> 
> This error means that your OpenJDK build contains the translation for your locale, and different tools use the resource bundles to translate different outputs. Looks like nobody validates that the translated output is correct for the various cases since the tests fail on non-US translated locales. I guess in the ideal world that tests should be updated to validate the output for each locale, or probably even better they should check that the output is correct for some specific "key" in the resource bundle.
> 
> The current issue is different, it fixes the tests depended on some specific float format and has no dependency on the resource bundles.

I still don't understand why the failures are different.

But the fix doesn't work even with these 4 tests.


* Before this fix: make test TEST="..."

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/langtools/jdk/jshell/ToolBasicTest.java
>>                                                       1     0     1     0 <<
   jtreg:test/langtools/jdk/jshell/ToolSimpleTest.java
>>                                                       1     0     1     0 <<
   jtreg:test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java
                                                         1     1     0     0
   jtreg:test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java
                                                         1     1     0     0
==============================
TEST FAILURE



* After this fix: make test TEST="..."

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/langtools/jdk/jshell/ToolBasicTest.java
>>                                                       1     0     1     0 <<
   jtreg:test/langtools/jdk/jshell/ToolSimpleTest.java
>>                                                       1     0     1     0 <<
   jtreg:test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java
                                                         1     1     0     0
   jtreg:test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java
                                                         1     1     0     0
==============================
TEST FAILURE


But if I run with make test JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" TEST="...", all of them get passed.

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

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

From serb at openjdk.java.net  Sat Sep 25 10:01:50 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 25 Sep 2021 10:01:50 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <-6m-FQLBb9SgouaBObjGmNW0eukggujk_gVgqxv4Nmc=.c3887d22-1163-48e5-8d74-a870770abd39@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>
Message-ID: <6Xtrgr_XaaB4_i80BPEbX2AnT6QFE16kmEGMHyIn9lA=.336d6708-9709-41cd-88c4-69975899f8bf@github.com>

On Sat, 25 Sep 2021 07:38:54 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I still don't understand why the failures are different.

The difference is that if the test uses golden data for EN locale only while the tested tool like javac supports more than one locale for some specific output message then the test should check that specific localized message.

> But the fix doesn't work even with these 4 tests.

Look like you use one of ja or zh_CN locales since only for these locales there are translations, the test should take it into account. It is not strictly correct to run add "-Duser.language=en -Duser.country=US" to it to fix such issues.

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

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

From jiefu at openjdk.java.net  Sat Sep 25 12:12:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 25 Sep 2021 12:12:53 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <6Xtrgr_XaaB4_i80BPEbX2AnT6QFE16kmEGMHyIn9lA=.336d6708-9709-41cd-88c4-69975899f8bf@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>
Message-ID: <dkln0dazIDjEGd1PL0SoapfuomyHQqBuLx6Amig4oSo=.7735abe3-0eb7-4be7-a4a8-ed18c143b5ed@github.com>

On Sat, 25 Sep 2021 09:58:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I still don't understand why the failures are different.
> 
> The difference is that if the test uses golden data for EN locale only while the tested tool like javac supports more than one locale for some specific output message then the test should check that specific localized message.
> 
> > But the fix doesn't work even with these 4 tests.
> 
> Look like you use one of ja or zh_CN locales since only for these locales there are translations, the test should take it into account. It is not strictly correct to run add "-Duser.language=en -Duser.country=US" to it to fix such issues.

Thanks @mrserb for your clarification.

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.

And do you test the fix on Linux?
Thanks.

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

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

From itakiguchi at openjdk.java.net  Thu Sep 30 09:46:45 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 30 Sep 2021 09:46:45 GMT
Subject: RFR: 8274544: Langtools command's usage were grabled on Japanese
 Windows
Message-ID: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@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.

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

Commit messages:
 - Langtools command's usage were grabled on Japanese Windows

Changes: https://git.openjdk.java.net/jdk/pull/5771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274544
  Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 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  Thu Sep 30 10:13:32 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 30 Sep 2021 10:13: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: <YCW8f5kU2eVwv6IMrXl2czyQOG0R-UydRDRTAJuC-TA=.e1dc8088-bd67-432e-b578-49f2b86d313e@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.

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.

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

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

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

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

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

What was the cause of the failure?

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

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

> 
> jshell does not work as expected on b12

Do you mean `b13`?

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

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

Naoto

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

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