From shade at openjdk.org  Thu Dec  1 08:14:35 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Dec 2022 08:14:35 GMT
Subject: Integrated: 8297821: jdk/jshell/Test8294583.java fails on some
 platforms
In-Reply-To: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>
References: <-o867fNp3N_X9dKiA0gGbPNecCMOpzuNOBufDrZ_bf4=.67ca4429-df40-4a34-ae64-6eee24133645@github.com>
Message-ID: <1BN-fk1pHPhbLgi9HABZmJsXgpSau8AQ6O54rk877gY=.0483f1c2-af77-4a4e-a8a3-72ced674c813@github.com>

On Wed, 30 Nov 2022 08:39:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8294583](https://bugs.openjdk.org/browse/JDK-8294583) added a new test that does `--enable-preview` to access new language constructs. Unfortunately, this test also enables Loom, which on some platforms like x86_32 uses the 1:1 fallback emulation, which does not support JVMTI. JShell apparently uses JDI -> JDWP -> JVMTI to work, and thus the test fails.
> 
> More logs in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, test still passes
>  - [x] Linux x86_32 fastdebug, test is now skipped

This pull request has now been integrated.

Changeset: 34fcd83c
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34fcd83c5ea54f94b60ebda0a111d0fe8ea9cbec
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8297821: jdk/jshell/Test8294583.java fails on some platforms

Reviewed-by: alanb, jlahoda

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

PR: https://git.openjdk.org/jdk/pull/11428

From jlaskey at openjdk.org  Thu Dec  1 13:18:16 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Dec 2022 13:18:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <xhPzR2HTM7U0UEhvRxjpaE0ff169w3tCBX0yCpLOoY4=.be878d0b-bfc3-4d4c-a9d5-37369616e413@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Thu Dec  1 15:11:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:11:23 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <Scdy9u1XjWQU5gWdMdr_25uiTCXFpTSToGd46dM8frw=.acb5fc20-e233-436e-a39b-c94836bbeb7c@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

src/java.base/share/classes/java/io/Console.java line 604:

> 602:                             GetPropertyAction.privilegedGetProperty("jdk.console",
> 603:                                     JdkConsoleProvider.DEFAULT_PROVIDER);
> 604:                     cons = ServiceLoader.load(JdkConsoleProvider.class).stream()

We might need a test to verify that this works when running with a security manager? That execution mode is still supported.

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Thu Dec  1 15:18:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:18:39 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

src/java.base/share/classes/java/lang/System.java line 2133:

> 2131:     }
> 2132: 
> 2133:     private static InputStream initIn = null;

I think it would be helpful to rename this to `initialIn` and move this to be with `in` and `out`. It might also be helpful to have a  comment to say that it's the initial value of `in`, set in initPhase1.  It doesn't need to be initialized to null as that it's default value anyway.

src/java.base/share/classes/sun/security/util/Password.java line 63:

> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
> 62:                 // to be compatible with old Password class, change to null
> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {

@wangweij Would you have cycles to build with this change to see that keytool is okay?

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Thu Dec  1 15:35:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Dec 2022 15:35:34 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
Message-ID: <R4aKXarc67PDUTPbROJ23XQVirwJEVTMRkBIdSGGTtY=.ee02bf33-a445-44aa-a9f9-5e65284506ab@github.com>

On Wed, 30 Nov 2022 20:44:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adds a test
>  - Removed JavaIOAccess.charset() which is no longer needed

A general point is that it's difficult to test Console and it looks like we don't have many existing tests in test/jdk/java/io/Console. The test that is there doesn't seem to exercise most of the methods. I wonder should improve this and have the tests run with `--limit-modules java.base` so they run with the default the is in java.base rather than the provider in jdk.intenal.le.

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

PR: https://git.openjdk.org/jdk/pull/11421

From weijun at openjdk.org  Thu Dec  1 15:53:27 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 15:53:27 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
Message-ID: <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>

On Thu, 1 Dec 2022 15:16:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Adds a test
>>  - Removed JavaIOAccess.charset() which is no longer needed
>
> src/java.base/share/classes/sun/security/util/Password.java line 63:
> 
>> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
>> 62:                 // to be compatible with old Password class, change to null
>> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {
> 
> @wangweij Would you have cycles to build with this change to see that keytool is okay?

Sure. Trying out now...

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

PR: https://git.openjdk.org/jdk/pull/11421

From weijun at openjdk.org  Thu Dec  1 16:11:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 16:11:12 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
Message-ID: <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>

On Thu, 1 Dec 2022 15:49:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/Password.java line 63:
>> 
>>> 61:                 // readPassword returns "" if you just press ENTER with the built-in Console,
>>> 62:                 // to be compatible with old Password class, change to null
>>> 63:                 if (consoleEntered == null || consoleEntered.length == 0) {
>> 
>> @wangweij Would you have cycles to build with this change to see that keytool is okay?
>
> Sure. Trying out now...

I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.

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

PR: https://git.openjdk.org/jdk/pull/11421

From weijun at openjdk.org  Thu Dec  1 17:56:17 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 17:56:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
Message-ID: <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>

On Thu, 1 Dec 2022 16:08:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sure. Trying out now...
>
> I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.
> 
> $ jshell -C--add-exports -Cjava.base/sun.security.tools.keytool=ALL-UNNAMED -R--add-exports -Rjava.base/sun.security.tools.keytool=ALL-UNNAMED
> |  Welcome to JShell -- Version 20-internal
> |  For an introduction type: /help intro
> 
> jshell> sun.security.tools.keytool.Main.main("-genkeypair -keyalg EC -alias a -dname CN=A -keystore ks".split(" "))
> Enter keystore password:  changeit
> Re-enter new password: changeit
> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days
> 	for: CN=A

What's the expected behavior?

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Thu Dec  1 19:34:35 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Dec 2022 19:34:35 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
Message-ID: <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>

On Thu, 1 Dec 2022 17:53:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I can still see the password on screen. Here `in` is a `jdk.jshell.execution.Util` so the updated check on line 58 above failed.
>> 
>> $ jshell -C--add-exports -Cjava.base/sun.security.tools.keytool=ALL-UNNAMED -R--add-exports -Rjava.base/sun.security.tools.keytool=ALL-UNNAMED
>> |  Welcome to JShell -- Version 20-internal
>> |  For an introduction type: /help intro
>> 
>> jshell> sun.security.tools.keytool.Main.main("-genkeypair -keyalg EC -alias a -dname CN=A -keystore ks".split(" "))
>> Enter keystore password:  changeit
>> Re-enter new password: changeit
>> Generating 384 bit EC (secp384r1) key pair and self-signed certificate (SHA384withECDSA) with a validity of 90 days
>> 	for: CN=A
>
> What's the expected behavior?

I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.

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

PR: https://git.openjdk.org/jdk/pull/11421

From weijun at openjdk.org  Thu Dec  1 23:41:12 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Dec 2022 23:41:12 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
Message-ID: <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>

On Thu, 1 Dec 2022 19:30:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> What's the expected behavior?
>
> I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.

If the console cannot be used anyway inside jshell, then this is good enough.

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Fri Dec  2 08:21:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Dec 2022 08:21:05 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
Message-ID: <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>

On Thu, 1 Dec 2022 23:38:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I confirmed that the standalone `keytool` did not echo the input, which should be OK for this IMO.
>
> If the console cannot be used anyway inside jshell, then this is good enough.

Naoto has confirmed that the password prompt from keytool does not echo, good!

The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.

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

PR: https://git.openjdk.org/jdk/pull/11421

From erikj at openjdk.org  Fri Dec  2 14:31:00 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 Dec 2022 14:31:00 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v30]
In-Reply-To: <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <kstu-zmyhVPARnuKs2ocWm-2DCzB81ScVIGr5BmRBMI=.1a12f859-6a34-4760-8e15-48c9ee98b14b@github.com>
 <ol0E1_Wje0XRQgoaDlbboZ9l_Zr9vV3dQ_VoryUJphg=.70bd7bd1-c56f-420e-a0e4-7fca91776d9c@github.com>
Message-ID: <Bz9N4O4qUKCuVAt7ZoAZl1FkR48qI6iKm_S0FiJDANs=.511266f5-95b3-4e0b-82f6-fb5730ecdae2@github.com>

On Wed, 23 Nov 2022 15:38:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > /issue add JDK-8296302
> 
> The BOT comment at the top says /issue cannot refer to a CSR. You'll need to /issue remove it before integration.

Roger is correct, please do not add CSR issues with `/issue add`. The bot should auto discover CSRs if linked correctly in JBS. You need to `/issue remove` the CSR.

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

PR: https://git.openjdk.org/jdk/pull/10889

From weijun at openjdk.org  Fri Dec  2 15:23:51 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 2 Dec 2022 15:23:51 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
 <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
Message-ID: <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>

On Fri, 2 Dec 2022 08:18:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If the console cannot be used anyway inside jshell, then this is good enough.
>
> Naoto has confirmed that the password prompt from keytool does not echo, good!
> 
> The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.

Still not sure what the expected behavior is, but for keytool, because of the updated check, `sun.security.util.Password` now uses `System.in.read` instead of `Console.readPassword`, therefore the password is echoing. I tried removing the check and force `Console.readPassword` to be called. There is no echo but the return key also does not work. I have to Ctrl-C to break out.

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

PR: https://git.openjdk.org/jdk/pull/11421

From ihse at openjdk.org  Fri Dec  2 16:46:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:46:11 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
Message-ID: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>

According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.

We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").

After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)

Doing so has a dual benefit:

1) It makes it clear to everyone reading the code that there is a trailing space and it is intended

2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.

Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

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

Commit messages:
 - 8298044: Fix hidden but significant trailing whitespace in properties files for langtools code

Changes: https://git.openjdk.org/jdk/pull/11487/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298044
  Stats: 18 lines in 10 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/11487.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11487/head:pull/11487

PR: https://git.openjdk.org/jdk/pull/11487

From ihse at openjdk.org  Fri Dec  2 16:46:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:46:11 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <vOT287F-td6cT6UHj7rw3ER9XFJKOX6j9ybpiH34WS0=.a736db14-bc4c-4227-aaf2-a9184bc79ab1@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

**A note to reviewers:**

This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences.

In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed.

I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: 
If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR.

But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you.

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

PR: https://git.openjdk.org/jdk/pull/11487

From jlaskey at openjdk.org  Fri Dec  2 16:51:48 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Dec 2022 16:51:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v32]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <U2ZZfoc2VKb3KdXhEy9dKR4yU6lUeawIDV9auD3nGkI=.fc56de1c-6752-4a41-ab64-6b33f784ad29@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:

 - Merge branch 'master' into 8285932
 - FormatProcessor changes
 - Update @since
 - Requested changes #12
 - Seal Digits
 - Requested changes #11
 - Typo
 - Requested changes #10
 - Requested changes #9
 - Requested changes #8
 - ... and 37 more: https://git.openjdk.org/jdk/compare/6065696e...581e0f7a

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=31
  Stats: 9519 lines in 81 files changed: 9356 ins; 28 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From ihse at openjdk.org  Fri Dec  2 17:12:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:37 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:

[JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.

[JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Dec  2 17:12:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:39 GMT
Subject: Withdrawn: 8295729: Add jcheck whitespace checking for properties
 files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <FucejIc47XdfLlKe8MOVxYBnv1k7GvnH1TgHiinx9ak=.b06a548a-3575-4456-8df4-f8804114105b@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10792

From angorya at openjdk.org  Fri Dec  2 17:15:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Dec 2022 17:15:19 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>

On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> and instead I have split up this work in five different bugs

would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

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

PR: https://git.openjdk.org/jdk/pull/10792

From naoto at openjdk.org  Fri Dec  2 21:55:24 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Dec 2022 21:55:24 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v3]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <HM5Wmd_ENr7tE83zt4n2wIIdfaD4OIapOcA5VfsYE1E=.55aff254-32c6-4771-9b5e-daedb07af297@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Added more tests, loading with doPrivileged()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/3d2b01f6..4c38b01b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=01-02

  Stats: 137 lines in 5 files changed: 121 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Fri Dec  2 22:03:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Dec 2022 22:03:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v2]
In-Reply-To: <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <C56hJA49q2N58Mt0V7NPJXtOK_x9esg97rdaGLUBthY=.df86bde2-7373-45ea-976c-5b120cf47052@github.com>
 <JCBfRAbsgf6bH6lqeXWodGC89bWpXwpwNlv2E1aHPUI=.85727228-d8c8-4918-818a-ae6606514b99@github.com>
 <ZTmLDk0M9hsuICQeazcIat8UdUvM49UAisgTfoV8LCg=.799c1bfe-57a8-4b24-a72e-ed7f970bcf95@github.com>
 <nrL_Up0TmjkjNZgQtxGCZG3gkOF2eg5FiJYUK_J1kJs=.164122ef-8750-487c-abc5-e5b92bdf7c2c@github.com>
 <no3fTAbXqXI9w9odDcE5nFpKzJWuUHHi9eOY04AXBAI=.fafda472-c4b3-4251-b496-f149e463bea4@github.com>
 <ktUnahpoaSsO7Ycw0Bav_j-Tb0iOA-4S3BpmK7h8LWo=.ad9b526a-f0d8-4963-a1c3-1f098d0fcbc6@github.com>
 <tP7Z8ToLzTciRkvSBXR5WlF65EGcVQ89tSvtSO3XCaw=.da2e4cdd-a652-4813-9fc5-62e1c50c1105@github.com>
 <ShycxtxiMZ0JMdI3EaSMKTHPO8NzJclj5VuOe2Xbqxk=.a8d846a6-0bc7-4a2e-83bb-224ed8a0e72e@github.com>
 <qq5C9afaTVN6a3JJci9IOrVN7eNsZY1o2OCdcN_abS4=.f1088244-a9fa-4227-93f5-7bfec38b4019@github.com>
Message-ID: <sLn0o9FkgSCSAKP-FGJCFYrPXh8soGDTi8I-1jktmzU=.02e644b1-48a6-41c2-b488-8b9ad7deeb17@github.com>

On Fri, 2 Dec 2022 15:21:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Naoto has confirmed that the password prompt from keytool does not echo, good!
>> 
>> The intention is that Console be usable in jshell so I think the issue is that readPassword is echo'ing when used in jshell. Maybe someone experimenting with the Console API might run into this but we can separate out that issue.
>
> Still not sure what the expected behavior is, but for keytool, because of the updated check, `sun.security.util.Password` now uses `System.in.read` instead of `Console.readPassword`, therefore the password is echoing. I tried removing the check and force `Console.readPassword` to be called. There is no echo but the return key also does not work. I have to Ctrl-C to break out.

I thought that in `jshell`, `System.console()` returns null, so it is always not using `Console.readPassword`. Anyway, I think the scenario is not practical (changing password using jshell), and in the future, jshell can provide its own Console implementation (that's a part of this enhancement's motivation) that would nicely handle this situation.

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

PR: https://git.openjdk.org/jdk/pull/11421

From ihse at openjdk.org  Fri Dec  2 23:06:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 23:06:08 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
 <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
Message-ID: <BJDInfZQ8pfjgoiYRHsRTcw2dxBWSu4ZcsNC0wktKPM=.9fef5722-e842-4119-a380-46b5dd3bbc02@github.com>

On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:
>> 
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.
>> 
>> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.
>
>> and instead I have split up this work in five different bugs
> 
> would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

@andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting.

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

PR: https://git.openjdk.org/jdk/pull/10792

From jjg at openjdk.org  Sat Dec  3 01:33:05 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 3 Dec 2022 01:33:05 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <OuwxEWxGXoHL8v7yO8cLObyH3RBpV1FIuwhu0W2NDi8=.61335f18-a62e-43b5-bbcc-c05e696c572a@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

All the files are localized versions of the underlying English files.

There are no changes in any of the underlying English files.  That suggests we should just let these localized versions "catch up" with the normal localization process, unless there is reason to believe that will not happen.

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

PR: https://git.openjdk.org/jdk/pull/11487

From naoto at openjdk.org  Sat Dec  3 19:18:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 3 Dec 2022 19:18:48 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Changed the expected behavior when the SecurityManager is enabled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/4c38b01b..7c0740aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=02-03

  Stats: 28 lines in 3 files changed: 5 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From jwaters at openjdk.org  Sun Dec  4 14:33:59 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 14:33:59 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <7I1sECma4ZPnJovaDu0nWm6IbIswf5cAq2OEI-pL2Ew=.ec62dcc8-e4f0-40f3-871f-068432123010@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

Just a heads up, this change seems to be responsible for the test failure on linux-x86 that's recently been persisting for quite a while

STDOUT:
config Test8296012.setUp(): failure
java.lang.IllegalStateException: Launching JShell execution engine threw: FailOverExecutionControlProvider: FAILED: 0:jdi:hostname(127.0.0.1) --
  Exception: java.lang.IllegalArgumentException: ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3

Some closer examination suggests that something about the way this test is configured is not agreeing with the JVMTI implementation inside HotSpot:
`src/hotspot/share/prims/jni.cpp GetEnv()`

// No JVM TI with --enable-preview and no continuations support.
if (!VMContinuations && Arguments::enable_preview() && JvmtiExport::is_jvmti_version(version)) {
  *penv = NULL;
  ret = JNI_EVERSION;
  return ret;
}

(JNI_EVERSION is -3, which is the same error code the test failure produces)

I'm unfortunately not in the position to set up a Linux x86 environment and figure out what exactly is going wrong at the moment

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

PR: https://git.openjdk.org/jdk/pull/11363

From jwaters at openjdk.org  Sun Dec  4 14:55:15 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 14:55:15 GMT
Subject: RFR: 8298067: Persistent test failures after 8296012
Message-ID: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>

After JDK-8296012 a langtools test consistently fails on x86 Linux. This is due to said test needing JVMTI and --enable-preview, but for both to be compatible VMContinuations needs to be manually enabled, since it is off by default on certain platforms. HotSpot otherwise rejects the JVMTI request if VMContinuations is not enabled

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

Commit messages:
 - Persistent test failures after 8296012

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

PR: https://git.openjdk.org/jdk/pull/11500

From jwaters at openjdk.org  Sun Dec  4 15:05:17 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 15:05:17 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <72pN1GWz5XJLLjax1sjOr2aKVclchq6JyfMl1aDgZas=.74c7abe8-469c-4981-a6f8-163cd019127b@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

Nevermind, the cause was simpler than I expected, -XX:-VMContinuations is not on by default for every platform. I've just created a quick fix for this

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

PR: https://git.openjdk.org/jdk/pull/11363

From abimpoudis at openjdk.org  Sun Dec  4 15:30:02 2022
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sun, 4 Dec 2022 15:30:02 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <aAzYTHXSp8ba_kAYChia8zp911b-iaOtj5mEJ0VFgsU=.777b0871-fb53-48b4-a917-8783cfd63d44@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

Thanks for the quick fix. However, why this commit triggered this failure? I assume `--enable-preview` is responsible for this. I wonder, no other JShell tests were passing `--enable-preview` before?

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

PR: https://git.openjdk.org/jdk/pull/11363

From alanb at openjdk.org  Sun Dec  4 16:11:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Dec 2022 16:11:16 GMT
Subject: RFR: 8298067: Persistent test failures after 8296012
In-Reply-To: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
References: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
Message-ID: <86QvWj-HcA6L7fdLJo9I1ln-tQzQDOa9VsDDILaceHM=.8d17984c-668f-45c3-ad05-c7490578548f@github.com>

On Sun, 4 Dec 2022 14:47:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After JDK-8296012 a langtools test consistently fails on x86 Linux. This is due to said test needing JVMTI and --enable-preview, but for both to be compatible VMContinuations needs to be manually enabled, since it is off by default on certain platforms. HotSpot otherwise rejects the JVMTI request if VMContinuations is not enabled

This is another test that needs `@requires vm.continuations`, look at test/langtools/jdk/jshell/Test8294583.java for an example.

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

PR: https://git.openjdk.org/jdk/pull/11500

From jwaters at openjdk.org  Sun Dec  4 17:14:01 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 17:14:01 GMT
Subject: RFR: 8298067: Persistent test failures after 8296012
In-Reply-To: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
References: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
Message-ID: <OzXIazXPN6FmsYDQ9aWhR-V31TGAXl1iaLXckr4u8Ok=.7b36af0f-580e-4d3b-a752-77740caa1a74@github.com>

On Sun, 4 Dec 2022 14:47:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After JDK-8296012 a langtools test consistently fails on x86 Linux. This is due to said test needing JVMTI and --enable-preview, but for both to be compatible VMContinuations needs to be manually enabled, since it is off by default on certain platforms. HotSpot otherwise rejects the JVMTI request if VMContinuations is not enabled

Alright, will do that asap

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

PR: https://git.openjdk.org/jdk/pull/11500

From alanb at openjdk.org  Sun Dec  4 17:17:02 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Dec 2022 17:17:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
Message-ID: <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>

On Sat, 3 Dec 2022 19:18:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the expected behavior when the SecurityManager is enabled

This is well done. I've been through all the latest src changes.

src/java.base/share/classes/java/io/Console.java line 627:

> 625:         });
> 626:     }
> 627:     private static Console cons;

The initialization of cons is replaced in this PR so maybe we can make it final at the same time.

src/java.base/share/classes/jdk/internal/io/JdkConsole.java line 33:

> 31: /**
> 32:  * Delegate interface for custom Console implementations.
> 33:  * Methods defined here are duplicating ones in Console class.

There's a typo here, probably should be be "duplicates the" or "are duplicates of the methods".

src/java.base/share/classes/jdk/internal/io/JdkConsoleProvider.java line 40:

> 38:      * The default provider of JdkConsole.
> 39:      */
> 40:     String DEFAULT_PROVIDER = "jdk.internal.le";

This is really the module name of the preferred provider, maybe it should have _MODULE_NAME as the suffix.

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

PR: https://git.openjdk.org/jdk/pull/11421

From jwaters at openjdk.org  Sun Dec  4 17:17:12 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 17:17:12 GMT
Subject: RFR: 8298067: Persistent test failures after 8296012 [v2]
In-Reply-To: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
References: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
Message-ID: <jL6zd_zAKDRcAP79oPPpirXWI0rTkTihPKd3KR0ZdF0=.9a743bd7-c144-4379-b774-967c35f7dad5@github.com>

> After JDK-8296012 a langtools test consistently fails on x86 Linux. This is due to said test needing JVMTI and --enable-preview, but for both to be compatible VMContinuations needs to be manually enabled, since it is off by default on certain platforms. HotSpot otherwise rejects the JVMTI request if VMContinuations is not enabled

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

  First try did not work, switch to @requires vm.continuations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11500/files
  - new: https://git.openjdk.org/jdk/pull/11500/files/48b68357..0defa77f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11500&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11500&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11500

From alanb at openjdk.org  Sun Dec  4 17:23:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Dec 2022 17:23:00 GMT
Subject: RFR: 8298067: Persistent test failures after 8296012 [v2]
In-Reply-To: <jL6zd_zAKDRcAP79oPPpirXWI0rTkTihPKd3KR0ZdF0=.9a743bd7-c144-4379-b774-967c35f7dad5@github.com>
References: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
 <jL6zd_zAKDRcAP79oPPpirXWI0rTkTihPKd3KR0ZdF0=.9a743bd7-c144-4379-b774-967c35f7dad5@github.com>
Message-ID: <8IHMk6Wk_FOtUKQcm5KFMpKaUCFztaO50-2xxASQeZI=.6487fe5b-cb01-40cd-b366-0d5d9e57fe2c@github.com>

On Sun, 4 Dec 2022 17:17:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After JDK-8296012 a langtools test consistently fails on x86 Linux. This is due to said test needing JVMTI and --enable-preview, but for both to be compatible VMContinuations needs to be manually enabled, since it is off by default on certain platforms. HotSpot otherwise rejects the JVMTI request if VMContinuations is not enabled
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   First try did not work, switch to @requires vm.continuations

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11500

From jwaters at openjdk.org  Sun Dec  4 17:30:56 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 17:30:56 GMT
Subject: RFR: 8298067: Persistent test failures after 8296012 [v2]
In-Reply-To: <jL6zd_zAKDRcAP79oPPpirXWI0rTkTihPKd3KR0ZdF0=.9a743bd7-c144-4379-b774-967c35f7dad5@github.com>
References: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
 <jL6zd_zAKDRcAP79oPPpirXWI0rTkTihPKd3KR0ZdF0=.9a743bd7-c144-4379-b774-967c35f7dad5@github.com>
Message-ID: <M-NAANah1LaokrcOAANnmu5tEVjEomWjY0Pce0rNt_E=.39161fc3-79e7-492a-833e-e7f22a965d57@github.com>

On Sun, 4 Dec 2022 17:17:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After JDK-8296012 a langtools test consistently fails on x86 Linux. This is due to said test needing JVMTI and --enable-preview, but for both to be compatible VMContinuations needs to be manually enabled, since it is off by default on certain platforms. HotSpot otherwise rejects the JVMTI request if VMContinuations is not enabled
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   First try did not work, switch to @requires vm.continuations

Thanks Alan for the review, will set to automatically integrate if there are no other objections

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

PR: https://git.openjdk.org/jdk/pull/11500

From jwaters at openjdk.org  Sun Dec  4 17:35:10 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 4 Dec 2022 17:35:10 GMT
Subject: Integrated: 8298067: Persistent test failures after 8296012
In-Reply-To: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
References: <W_3AkKn1jr9onaUiGWM92mFMR46UtYcMxW4OGssqGrc=.54dabde6-2a36-41e5-9769-097484cd6fd0@github.com>
Message-ID: <fJdp2Qs8C228QiarZFzU1W1VqXAbS4CYFxnWpMqqGMk=.65346682-feb8-417b-986d-168ef9886134@github.com>

On Sun, 4 Dec 2022 14:47:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After JDK-8296012 a langtools test consistently fails on x86 Linux. This is due to said test needing JVMTI and --enable-preview, but for both to be compatible VMContinuations needs to be manually enabled, since it is off by default on certain platforms. HotSpot otherwise rejects the JVMTI request if VMContinuations is not enabled

This pull request has now been integrated.

Changeset: a71d91b9
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a71d91b96f7936dd1b84e4c1e167e2e5fa4ad4b1
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8298067: Persistent test failures after 8296012

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk/pull/11500

From aturbanov at openjdk.org  Mon Dec  5 07:08:38 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Dec 2022 07:08:38 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
Message-ID: <dt5iQtdPZY3ZYgGq9Ol237Cp3z9DR5M6k_p1XsDHXh4=.bf2a1103-c8e8-4f7c-9b54-fcc908ece4f1@github.com>

On Sat, 3 Dec 2022 19:18:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed the expected behavior when the SecurityManager is enabled

src/java.base/share/classes/java/io/ProxyingConsole.java line 62:

> 60:      */
> 61:     @Override
> 62:     public Console format(String fmt, Object ...args) {

Suggestion:

    public Console format(String fmt, Object ... args) {

src/java.base/share/classes/jdk/internal/io/JdkConsole.java line 40:

> 38:     PrintWriter writer();
> 39:     Reader reader();
> 40:     JdkConsole format(String fmt, Object ...args);

nit
Suggestion:

    JdkConsole format(String fmt, Object ... args);

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 67:

> 65:         }
> 66: 
> 67:         public synchronized JdkConsole format(String fmt, Object ...args) {

Nit:
Suggestion:

        public synchronized JdkConsole format(String fmt, Object ... args) {

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

PR: https://git.openjdk.org/jdk/pull/11421

From jlahoda at openjdk.org  Mon Dec  5 07:19:43 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Dec 2022 07:19:43 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <SJ54H2Wd4DzQQnc8rVGrkRNAb0jDhN0r2_d-A4wg5uI=.5ba5096c-bd72-4e96-bdb4-24636088cfea@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

Hasn't the x86 failure been already resolved as https://github.com/openjdk/jdk/pull/11428 ?

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

PR: https://git.openjdk.org/jdk/pull/11363

From duke at openjdk.org  Mon Dec  5 07:25:59 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 07:25:59 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <ibwX-zVvNNEglc0O8Ath7yc_d7XiHJsBNRglPBU31F4=.e054fede-4d5a-4df5-9779-d5d9a95ac4a2@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties line 142:

> 140: doclet.Implementing_Classes=\u65E2\u77E5\u306E\u5B9F\u88C5\u30AF\u30E9\u30B9\u306E\u30EA\u30B9\u30C8:
> 141: doclet.Functional_Interface=\u6A5F\u80FD\u30A4\u30F3\u30BF\u30D5\u30A7\u30FC\u30B9
> 142: doclet.Functional_Interface_Message=\u3053\u308C\u306F\u6A5F\u80FD\u30A4\u30F3\u30BF\u30D5\u30A7\u30FC\u30B9\u306A\u306E\u3067\u3001\u30E9\u30E0\u30C0\u5F0F\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u53C2\u7167\u306E\u5272\u5F53\u3066\u30BF\u30FC\u30B2\u30C3\u30C8\u3068\u3057\u3066\u4F7F\u7528\u3067\u304D\u307E\u3059\u3002\u0020

standard.properties (en, de, zh) does not have a trailing white space for doclet.Functional_Interface_Message.

For consistency, there should not be a space here.

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

PR: https://git.openjdk.org/jdk/pull/11487

From duke at openjdk.org  Mon Dec  5 07:40:01 2022
From: duke at openjdk.org (Justin Lu)
Date: Mon, 5 Dec 2022 07:40:01 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <yBOkrZYiUK06kMHW4XJb_bxaO4kIaWJCwZBK3h28USk=.c17d71f8-5d83-45b5-83d5-c7df3b560b83@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 170:

> 168: jshell.console.no.javadoc = <Keine Dokumentation gefunden>
> 169: jshell.console.do.nothing = Nichts machen
> 170: jshell.console.choice = Auswahl:\u0020

This is correct.  However, the original l10n.properties did not get the change as intended.

l10n.properties had it implemented as 

`jshell.console.choice = Choice: `

The trailing white space was enclosed with a trailing `` (probably to signify the white space is intentional) and thus hidden from the script.

It should be changed to `jshell.console.choice = Choice:\u0020` for consistency

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

PR: https://git.openjdk.org/jdk/pull/11487

From jwaters at openjdk.org  Mon Dec  5 09:36:18 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Dec 2022 09:36:18 GMT
Subject: RFR: 8296012: jshell crashes on mismatched record pattern
In-Reply-To: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
References: <si0tJsCKePmyG3AykHxoktXNcUesYXPeHcc1AArI11w=.1159817d-dea0-45cc-b843-a3f561ce8fcc@github.com>
Message-ID: <LFho9wSB910fSN9KsmhpiX4Hd5WnO48D5JBPkmKETzY=.babf3e92-621d-42ec-884d-12400e4b4c85@github.com>

On Fri, 25 Nov 2022 10:55:03 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This bug prevents a crash in Flow while evaluating a switch expression in JShell. The error is successfully reported in Attr however entering an erroneous symbols prevents the crash.

> Hasn't the x86 failure been already resolved as #11428 ?

Not entirely, the test this change added also needed `@requires vm.continuations` as well. I've already pushed a fix for it, so it should be good now

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

PR: https://git.openjdk.org/jdk/pull/11363

From naoto at openjdk.org  Mon Dec  5 18:26:17 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 18:26:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v5]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <ynj7DlOjqZgdAGPXz_J-CMPBPLJk6jsLCLpPPYKlDKg=.906b2710-397c-4411-831a-783000cf70cf@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Addressing review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/7c0740aa..00a0e3fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=03-04

  Stats: 57 lines in 5 files changed: 26 ins; 22 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Mon Dec  5 18:33:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 18:33:10 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v6]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  oleole -> ole

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/00a0e3fc..31656331

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/11421

From jlaskey at openjdk.org  Mon Dec  5 19:10:40 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Dec 2022 19:10:40 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v6]
In-Reply-To: <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <i01UZeZ93eF1q8deXQp1wjxZ7O3smDi9ZdVIU6uSBwg=.413f8efc-b873-4f8b-962c-4b8a0ba6441d@github.com>
Message-ID: <za2uEjGQFEz5J5OE0DGGh4CM8ReMsVWDEH1CP3tqn0Q=.ade0c382-0cba-4807-9590-ceae0ee59876@github.com>

On Mon, 5 Dec 2022 18:33:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oleole -> ole

LGTM

src/java.base/share/classes/jdk/internal/access/JavaIOAccess.java line 26:

> 24:  */
> 25: 
> 26: package jdk.internal.access;

Update copyright

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

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Mon Dec  5 19:52:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 19:52:59 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Fixed the copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/31656331..8b6859ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Mon Dec  5 19:53:03 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Dec 2022 19:53:03 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v4]
In-Reply-To: <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <01thVeD5joKRB8oex093EUINsuSrfs2HHXEL_MMEtJU=.83c39abd-0f31-4609-b7ed-731f3ed8f342@github.com>
 <hqHxUOYYwCX6hwRyijObfuLqEycrWhYQuNlk5i1ayV4=.76a1e3d1-fb08-4e89-a5d9-fe30b22e154b@github.com>
Message-ID: <RmT1uDPVJaVYkXuvqLhsNo2qMYrJ6INV5Q84sREuzp8=.23beb44f-4e94-499b-9e0f-f6b07d789558@github.com>

On Sun, 4 Dec 2022 17:09:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed the expected behavior when the SecurityManager is enabled
>
> src/java.base/share/classes/java/io/Console.java line 627:
> 
>> 625:         });
>> 626:     }
>> 627:     private static Console cons;
> 
> The initialization of cons is replaced in this PR so maybe we can make it final at the same time.

Changed it to final

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

PR: https://git.openjdk.org/jdk/pull/11421

From jlaskey at openjdk.org  Mon Dec  5 20:07:45 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Dec 2022 20:07:45 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <UR7qa0ZKDOWbPDheSyV0-EdLU1f5RQn1eLUFbG-VWsQ=.b6701fd3-6968-4b9f-9506-0a866f095b1e@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

Marked as reviewed by jlaskey (Reviewer).

Marked as reviewed by jlaskey (Reviewer).

LGTM

Marked as reviewed by jlaskey (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11421Marked as reviewed by jlaskey (Reviewer).

From jpai at openjdk.org  Tue Dec  6 06:06:44 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:06:44 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <jCZcWYzVC1Sp_rkTvRHeSBUowXx1BCkTA_HnB8Be9KQ=.af7eb51a-5d9a-4666-bf34-65d48dae1319@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 50:

> 48:      * {@inheritDoc}
> 49:      */
> 50:     public JdkConsole console(boolean isTTY) {

Hello Naoto, this is missing a `@Override`.

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 58:

> 56:      * public Console class.
> 57:      */
> 58:     public static class JdkConsoleImpl implements JdkConsole {

Can this be `private` class? Also, the methods in this class are missing the `@Override`.

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

PR: https://git.openjdk.org/jdk/pull/11421

From jpai at openjdk.org  Tue Dec  6 06:16:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:16:09 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <WOH-ibxViM4sSleRr3z7nWv1y_MsN7M6EZCNZhUBfbU=.ad011b20-1bd1-4b75-9926-29c8ce6317d9@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 113:

> 111:         public JdkConsoleImpl() {
> 112:             try {
> 113:                 terminal = TerminalBuilder.builder().build();

The `java.io.Console` in its static initialization code has some logic to determine the `Charset` to use. Should that same `Charset` (or logic) be used here to build the terminal? Something like `TerminalBuilder.builder().encoding(fooBarCharset).build();`.

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

PR: https://git.openjdk.org/jdk/pull/11421

From jpai at openjdk.org  Tue Dec  6 06:22:02 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 06:22:02 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 99:

> 97:  */
> 98: 
> 99: public class Console implements Flushable

Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?

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

PR: https://git.openjdk.org/jdk/pull/11421

From jpai at openjdk.org  Tue Dec  6 07:02:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:02:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <CkmM7v_Lh-rsQ8_sRfxIuHqsonz2GzXleEQ44vTD0Ig=.d3b44b2c-6d14-4f12-aeba-805ad2a62539@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 615:

> 613:                 var consModName = System.getProperty("jdk.console",
> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()

Are we intentionally using thread context classloader (which can be different depending on which caller ends up first accessing/initializing the `java.io.Console` class) to load these services?

I initially thought that `java.io.Console` might be used/initialized early in the bootstrap process of Java so the classloader could perhaps be deterministic, but running a trivial Java application with `-verbose:class` shows that `java.io.Console` doesn't get instantiated during the launch, so that leaves this code to "first access wins" situation and maybe an "incorrect" context classloader which doesn't have access the configured `jdk.console` module may end up causing this code to default to `java.io.Console`?


public class Hello {
	public static void main(final String[] args) {
	}
}


java -verbose:class Hello.java


Instead, should we perhaps use the ModuleLayer to find this configured module and then use its classloader to load the `JdkConsoleProvider` service provider? Something like:


final Optional<Module> mod = ModuleLayer.boot().findModule(consModName);
// ... if not present default to java.io.Console else use the module's classloader to try and load the JdkConsoleProvider
return ServiceLoader.load(JdkConsoleProvider.class, mod.get().getClassLoader()).stream()......

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

PR: https://git.openjdk.org/jdk/pull/11421

From jpai at openjdk.org  Tue Dec  6 07:11:17 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:11:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 616:

> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
> 616:                         .map(ServiceLoader.Provider::get)

Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.

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

PR: https://git.openjdk.org/jdk/pull/11421

From jpai at openjdk.org  Tue Dec  6 07:18:14 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:18:14 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <GATX3t9zGQviww5AKhDFAkThUgIg6Woa04HuZw3ZlsA=.d580348b-e014-4020-aec3-034cff83d1e6@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

src/java.base/share/classes/java/io/Console.java line 625:

> 623:             };
> 624:             return AccessController.doPrivileged(pa);
> 625:         } catch (ServiceConfigurationError ignore) {

Should we perhaps just catch `Throwable` here since it's possible that the `PrivelegedAction` code could throw unchecked exception (for example the call to `JdkConsoleProvider.console()` could, in theory, lead to any kind of unchecked exceptions or errors like `NoClassDefFoundError`).

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

PR: https://git.openjdk.org/jdk/pull/11421

From jpai at openjdk.org  Tue Dec  6 07:38:52 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Dec 2022 07:38:52 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
Message-ID: <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>

On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the copyright year

Hello Naoto, the class level javadoc of `java.io.Console` currently specifies synchronization expectations in the context of multithreaded use:

>  Read and write operations are synchronized to guarantee the atomic
>  completion of critical operations; therefore invoking methods
>  {@link #readLine()}, {@link #readPassword()}, {@link #format format()},
>  {@link #printf printf()} as well as the read, format and write operations
>  on the objects returned by {@link #reader()} and {@link #writer()} may
>  block in multithreaded scenarios.

So the `Console` instance returned from `System.console()`, thus far, follows these semantics. However, with the change proposed in this PR, the default implementation will now be the jline backed `JdkConsoleImpl` implementation. From what I can see there, we don't seem to have any similar guarantees around multithreaded access. Do we need similar locking constructs in that implementation to guarantee/verify it works as per the expectations of `java.io.Console` API?

While we are at it, the Console class level javadoc also states:

> If the virtual machine is started from an
> interactive command line without redirecting the standard input and
> output streams then its console will exist and will typically be
> connected to the keyboard and display from which the virtual machine
> was launched.

With this proposed change, to by default use the jline backed implementation, would we need to reword/update that javadoc?

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Tue Dec  6 07:38:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 07:38:55 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
Message-ID: <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>

On Tue, 6 Dec 2022 07:08:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.

You are right that the ServiceLoader.load should specify the system class loader or the boot layer. However, there isn't an accessibility issue as a class loader just load classes so it's more about visibility and whether the TCCL will ultimately delegate to the application class loader.

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Tue Dec  6 12:11:08 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Dec 2022 12:11:08 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <zThZp7wk1n91h_yRdhoZXu839z0MV1cstLA-G7YOqlQ=.5822f9c8-e932-446f-885a-0e00b7405800@github.com>
Message-ID: <qHY5N00TioxM21y-BFNYHepWP6wM7O-0xBvTMkHmiGM=.6897a418-7b87-44f4-aa76-ee206a2d29ac@github.com>

On Tue, 6 Dec 2022 07:35:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> So the `Console` instance returned from `System.console()`, thus far, follows these semantics. However, with the change proposed in this PR, the default implementation will now be the jline backed `JdkConsoleImpl` implementation. From what I can see there, we don't seem to have any similar guarantees around multithreaded access. Do we need similar locking constructs in that implementation to guarantee/verify it works as per the expectations of `java.io.Console` API?

As it happens I was chatting with Naoto about this area yesterday. There are effectively two Console implementations, the base implementation in Console, and the subclass in ProxyingConsole. When using ProxyingConsole then the state/implementation in the superclass isn't used. So either the locks are exposed to the subclass or there is a bit more surgery done so there are two subclasses, each with their own read and write locks. Subclasses might be cleaned as there is state in Console that is not interesting for the new implementation.

> With this proposed change, to by default use the jline backed implementation, would we need to reword/update that javadoc?

That is a good observation, instead of "will typically not have a console" then it should probably say "may not have a console".

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Tue Dec  6 18:01:27 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:01:27 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v8]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Hgi1xIbIUO4QdDPDs3iYPYBi5j6iXb5BGXa6sbuNm7w=.741f911f-e343-4a52-9e01-41549509fb9e@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

 - Addressing review comments
 - Merge branch 'master' into JDK-8295803-PluginConsole
 - Fixed the copyright year
 - oleole -> ole
 - Addressing review comments.
 - Changed the expected behavior when the SecurityManager is enabled
 - Added more tests, loading with doPrivileged()
 - Adds a test
 - Removed JavaIOAccess.charset() which is no longer needed
 - Minor fixup
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ce6f50f2...204690cf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/8b6859ed..204690cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=06-07

  Stats: 47908 lines in 1086 files changed: 19444 ins; 21552 del; 6912 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Tue Dec  6 18:13:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:13:21 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
Message-ID: <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>

On Tue, 6 Dec 2022 06:19:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed the copyright year
>
> src/java.base/share/classes/java/io/Console.java line 99:
> 
>> 97:  */
>> 98: 
>> 99: public class Console implements Flushable
> 
> Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?

Right. Will address it after this PR.

> src/java.base/share/classes/java/io/Console.java line 615:
> 
>> 613:                 var consModName = System.getProperty("jdk.console",
>> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
>> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
> 
> Are we intentionally using thread context classloader (which can be different depending on which caller ends up first accessing/initializing the `java.io.Console` class) to load these services?
> 
> I initially thought that `java.io.Console` might be used/initialized early in the bootstrap process of Java so the classloader could perhaps be deterministic, but running a trivial Java application with `-verbose:class` shows that `java.io.Console` doesn't get instantiated during the launch, so that leaves this code to "first access wins" situation and maybe an "incorrect" context classloader which doesn't have access the configured `jdk.console` module may end up causing this code to default to `java.io.Console`?
> 
> 
> public class Hello {
> 	public static void main(final String[] args) {
> 	}
> }
> 
> 
> java -verbose:class Hello.java
> 
> 
> Instead, should we perhaps use the ModuleLayer to find this configured module and then use its classloader to load the `JdkConsoleProvider` service provider? Something like:
> 
> 
> final Optional<Module> mod = ModuleLayer.boot().findModule(consModName);
> // ... if not present default to java.io.Console else use the module's classloader to try and load the JdkConsoleProvider
> return ServiceLoader.load(JdkConsoleProvider.class, mod.get().getClassLoader()).stream()......

Changed it to use the boot layer `ServiceLoader.load(ModuleLayer.boot(), JdkConsoleProvider.class)`

> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 113:
> 
>> 111:         public JdkConsoleImpl() {
>> 112:             try {
>> 113:                 terminal = TerminalBuilder.builder().build();
> 
> The `java.io.Console` in its static initialization code has some logic to determine the `Charset` to use. Should that same `Charset` (or logic) be used here to build the terminal? Something like `TerminalBuilder.builder().encoding(fooBarCharset).build();`.

Initially, I thought of having charset as an argument to the constructor but realized jline would delve into the platform and figure out the same encoding, so I omitted it. However now I realized that the user could specify the standard out encoding via the `stdout/err.encoding` system property. So I revived the charset argument, as in your suggestion.

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Tue Dec  6 18:13:22 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 18:13:22 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <rzPVmUKQdK06b_4r9uiV6v_HM26LkdVGmf2BzpdGBXQ=.d882201a-01bf-429c-9ab5-4946a71b02b4@github.com>
 <aRStSfbyYDxmNb1dKkfmvu2sLsOygInBUAZiWyQ0q4A=.81384435-4139-4761-af05-66a9d24cb2e4@github.com>
Message-ID: <2uHRKaMBaLaQmhYzbo1yOetB4DYyrbm7rxW-sFGg0n8=.4e8e537d-e6a3-4299-81a2-b93147359be0@github.com>

On Tue, 6 Dec 2022 07:34:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 616:
>> 
>>> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
>>> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
>>> 616:                         .map(ServiceLoader.Provider::get)
>> 
>> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.
>
>> Furthermore, I think in its current form it means that this will load/instantiate any `JdkConsoleProvider` implementations that are accessible to the thread context classloader but may not have been from the module configured through `jdk.console` system property. That could potentially mean, in the best case, unnecessary classloading of additional classes and in the worst case, could result in `ServiceLoader.Provider::get` throwing a `ServiceConfigurationError` error for any of such unused provider implementations, thus forcing us to use `java.io.Console` instance.
> 
> You are right that the ServiceLoader.load should specify the system class loader or the boot layer. However, there isn't an accessibility issue as a class loader just load classes so it's more about visibility and whether the TCCL will ultimately delegate to the application class loader.

`module-info.java` in the java.base only allows `jdk.internal.le` and `jdk.jshell` modules to access the `jdk.internal.io.JdkConsoleProvider` interface. So unless the user intentionally exports it, no other implementations are effectively instantiated.

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Tue Dec  6 19:17:44 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 19:17:44 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v9]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Further addressing review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/204690cf..6cd9843e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=07-08

  Stats: 27 lines in 2 files changed: 20 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Tue Dec  6 19:24:20 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 19:24:20 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v9]
In-Reply-To: <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <NH-VgRl9JdgGTj1jxQPiyUsKyh5X-zEHyLMWIa47zu0=.611a1828-80b9-4aac-8c1d-82f93ce4e4e4@github.com>
Message-ID: <IxAskDLUnZ5MlMZA2jJlX3U5oAFCOD6r1Fk1X5_LSG0=.aa91a045-dfee-4698-ab4b-d494893c426d@github.com>

On Tue, 6 Dec 2022 19:17:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further addressing review comments.

Provided separate independent locks in `ProxyingConsole` for now. Later it can be re-org'ed as Alan suggested for cleaner implementation/interface separation.

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Tue Dec  6 21:48:36 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 21:48:36 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v10]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <lpDoiTBG0BCmcakQz2tdNL5nt_mAdbbJdhdzhsb5Vhc=.5b6e55fa-a606-464b-a623-bd5181dffa32@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Synchronize reader/writer by wrapping them

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/6cd9843e..a54aed5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=08-09

  Stats: 56 lines in 1 file changed: 54 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Tue Dec  6 22:45:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Dec 2022 22:45:52 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Making the wrapper classes static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/a54aed5f..40de5d0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=09-10

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Wed Dec  7 07:09:14 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 07:09:14 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <3c0_fD_pzDxeZ6ikjh0LlCmtpI6JqY0OJyXeLvT694w=.bfe0d4ad-313c-4094-a526-d2d29902fa6b@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/ProxyingConsole.java line 153:

> 151: 
> 152:         WrappingReader(Reader r, Object lock) {
> 153:             this.r = r;

I think you need super(lock) here to ensure that the Reader uses the same lock.

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Wed Dec  7 07:12:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 07:12:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <fQcZuAPbgcoiXN9XADjzVLxEaYP8u3TciMbkzsmH5xc=.c9c58b39-28d3-458a-b4f4-97065bcaef65@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/ProxyingConsole.java line 175:

> 173: 
> 174:         public WrappingWriter(PrintWriter pw, Object lock) {
> 175:             super(pw);

PrintWriter doesn't provide a way to provide to lock object so this means the overridden methods will synchronize on "lock", the non-overridden methods will synchronize on "pw". So we will need to look at this.

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Wed Dec  7 11:58:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 11:58:10 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
Message-ID: <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>

On Tue, 6 Dec 2022 22:45:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Making the wrapper classes static

src/java.base/share/classes/java/io/Console.java line 625:

> 623:             };
> 624:             return AccessController.doPrivileged(pa);
> 625:         } catch (Throwable ignore) {

I don't think we should be catching and ignoring throwable here. The only case that would be okay to ignore here is SCE due to SecurityException as the jline provider doesn't work with a SM set.

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Wed Dec  7 17:09:53 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 17:09:53 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/40de5d0a..187f94fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=10-11

  Stats: 10 lines in 3 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Wed Dec  7 17:09:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 17:09:56 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v11]
In-Reply-To: <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <l6LdCakkTqmWO4D-om35LxcrFtrGDaKNeNdLtQjD6Ac=.d61eb655-dfee-4d75-89ae-10faae3978fb@github.com>
 <X70i0DJuWySlOcLcVntBQZ5Oq2_5y_Cmd1RNP4ud6Vw=.2c84f607-cc40-43cf-88cc-4c4599ad03ba@github.com>
Message-ID: <byXWsns6Ak-qqqiCaBka1snSKZd2Cov3tmuz3SBt1MA=.b6f6045a-eced-4a78-b279-fc3043082680@github.com>

On Wed, 7 Dec 2022 11:54:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Making the wrapper classes static
>
> src/java.base/share/classes/java/io/Console.java line 625:
> 
>> 623:             };
>> 624:             return AccessController.doPrivileged(pa);
>> 625:         } catch (Throwable ignore) {
> 
> I don't think we should be catching and ignoring throwable here. The only case that would be okay to ignore here is SCE due to SecurityException as the jline provider doesn't work with a SM set.

OK, reverted the catch clause.

> src/java.base/share/classes/java/io/ProxyingConsole.java line 175:
> 
>> 173: 
>> 174:         public WrappingWriter(PrintWriter pw, Object lock) {
>> 175:             super(pw);
> 
> PrintWriter doesn't provide a way to provide to lock object so this means the overridden methods will synchronize on "lock", the non-overridden methods will synchronize on "pw". So we will need to look at this.

Created a package private constructor just for `ProxyingConsole` to synchronize on the specified lock object.

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Wed Dec  7 19:01:16 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 19:01:16 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
Message-ID: <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>

On Wed, 7 Dec 2022 17:09:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

src/java.base/share/classes/java/io/PrintWriter.java line 212:

> 210: 
> 211:     /* package private constructor specific to ProxyingConsole */
> 212:     PrintWriter(Writer out, Object lock) {

This constructor looks fine but maybe the comment should just say that it allows the lock object to be provided rather than mentioning ProxyingConsole here.

src/java.base/share/classes/java/io/ProxyingConsole.java line 167:

> 165:         @Override
> 166:         public void close() throws IOException {
> 167:             r.close();

Console specifies that the invoking close on the Reader and Writer does not close the underlying stream. So I think this close (and WrappingWriter::close) need to be a no-op too.

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Wed Dec  7 19:19:25 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 19:19:25 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v13]
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

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

  Refined comments, no-op in WrappingReader/Writer::close()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11421/files
  - new: https://git.openjdk.org/jdk/pull/11421/files/187f94fb..ef1a74f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=11-12

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/11421.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Wed Dec  7 19:19:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 19:19:28 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v12]
In-Reply-To: <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Ca17Ww15KaZI94Q1s3B96D6noH9CGM7aY-SxlHoCu6A=.35df9f1c-2518-40a4-b384-028a4e134bb8@github.com>
 <JJ24W2UmLNW8Fx5HFMXce0Khjvn6pm6BBk6iO2cJP9I=.9aa7b966-96cc-4bf9-a96f-45f2ffd3abc7@github.com>
Message-ID: <kelivy29sGYuTkG19cOovkBz3kai5Cn_lhOGyP86uIQ=.9cd94465-4eef-4bdf-b3dc-7992a5eceb59@github.com>

On Wed, 7 Dec 2022 18:57:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 167:
> 
>> 165:         @Override
>> 166:         public void close() throws IOException {
>> 167:             r.close();
> 
> Console specifies that the invoking close on the Reader and Writer does not close the underlying stream. So I think this close (and WrappingWriter::close) need to be a no-op too.

Right. Made them as no-op.

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

PR: https://git.openjdk.org/jdk/pull/11421

From alanb at openjdk.org  Wed Dec  7 20:32:17 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Dec 2022 20:32:17 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v13]
In-Reply-To: <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <W8OZOfX1l4OTGU0n3W8anRu1Z-yH2R9-o1F4iyozFgY=.45380ebc-b3c2-4f5a-9165-4060e0bd30fe@github.com>
Message-ID: <Eqp_Y4HRUt6x1S881hkgco_Fa-uu54vmlsFNjOQU8T4=.1af56400-2f72-49b6-9edd-b85b7371e2c0@github.com>

On Wed, 7 Dec 2022 19:19:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refined comments, no-op in WrappingReader/Writer::close()

Marked as reviewed by alanb (Reviewer).

Thanks for the updates, I don't have any more comments. I think should create a follow-up issue to "hollow out" Console and have two separate implementations/subclasses. I think that would make it much cleaner rather than one implementation extending the other as we have now.

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Wed Dec  7 20:52:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Dec 2022 20:52:14 GMT
Subject: Integrated: 8295803: Console should be usable in jshell and other
 environments
In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
Message-ID: <bOnY-BRcoxyu7BXfC2PxL1Jg_7Fr3LzHoDwobCMf73I=.c16e77bf-b085-4006-8e32-da26783ee5c4@github.com>

On Tue, 29 Nov 2022 19:38:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.

This pull request has now been integrated.

Changeset: 8a9911ef
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a9911ef1762ae837e427ec9d91b1399ba33b6e4
Stats:     684 lines in 17 files changed: 661 ins; 11 del; 12 mod

8295803: Console should be usable in jshell and other environments

Reviewed-by: jlaskey, alanb

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

PR: https://git.openjdk.org/jdk/pull/11421

From naoto at openjdk.org  Thu Dec  8 19:41:18 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Dec 2022 19:41:18 GMT
Subject: RFR: 8295803: Console should be usable in jshell and other
 environments [v7]
In-Reply-To: <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>
References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com>
 <Y1mUiATfIgm77ycXgtVpaJZcCLJWFTs79AnTaMNUfyQ=.7186e11a-a462-4431-8cf5-c34155e145f9@github.com>
 <NBdqUPP-JYFqnssVlTqDa60SOyWjyrJvXPQ8DDWSImQ=.d07abcf6-b1e5-461b-81b9-07f5d4406907@github.com>
 <dWZf8Ig6HVqq-7sHncITq__8v0Bl3kYpCJdu-WUZn1o=.18639d8a-bdb3-47ea-8ab8-e29096886878@github.com>
Message-ID: <AoYsTXNvcGUUV_rDTPHUFJScUsjqqctuHp2Wa2l7770=.dcb7f0a9-1403-400f-a9a8-49c07cd129f8@github.com>

On Tue, 6 Dec 2022 18:10:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 99:
>> 
>>> 97:  */
>>> 98: 
>>> 99: public class Console implements Flushable
>> 
>> Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?
>
> Right. Will address it after this PR.

Filed: https://bugs.openjdk.org/browse/JDK-8298416

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

PR: https://git.openjdk.org/jdk/pull/11421

From jlahoda at openjdk.org  Fri Dec  9 13:22:20 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 9 Dec 2022 13:22:20 GMT
Subject: [jdk20] RFR: 8298425: System.console().readLine() hangs in jshell
Message-ID: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>

After https://bugs.openjdk.org/browse/JDK-8295803, JShell snippets like:

jshell> System.console().readLine()


hang, as the JLine console is used, and it cannot correctly read from the console while in the remote agent (due to input/output redirection setup for the agent). Until [JDK-8296454](https://bugs.openjdk.org/browse/JDK-8296454) is resolved, the JLine console should be disabled inside the remote agent.

As the default console requires an attached terminal, and there is no attached terminal inside the agent, `System.console()` should then return `null` inside the JShell's agent, which was the behavior before JDK-8295803.

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

Commit messages:
 - 8298425: System.console().readLine() hangs in jshell

Changes: https://git.openjdk.org/jdk20/pull/11/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298425
  Stats: 44 lines in 2 files changed: 44 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk20/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/11/head:pull/11

PR: https://git.openjdk.org/jdk20/pull/11

From alanb at openjdk.org  Fri Dec  9 15:21:58 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Dec 2022 15:21:58 GMT
Subject: [jdk20] RFR: 8298425: System.console().readLine() hangs in jshell
In-Reply-To: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
References: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
Message-ID: <nv0RrGKxfE6b8UQsZM93TpWXztCZ6aKhX6i5wwNsaTo=.31cd540d-a4e2-4129-a6f8-fde3b120ef1a@github.com>

On Fri, 9 Dec 2022 13:14:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> After https://bugs.openjdk.org/browse/JDK-8295803, JShell snippets like:
> 
> jshell> System.console().readLine()
> 
> 
> hang, as the JLine console is used, and it cannot correctly read from the console while in the remote agent (due to input/output redirection setup for the agent). Until [JDK-8296454](https://bugs.openjdk.org/browse/JDK-8296454) is resolved, the JLine console should be disabled inside the remote agent.
> 
> As the default console requires an attached terminal, and there is no attached terminal inside the agent, `System.console()` should then return `null` inside the JShell's agent, which was the behavior before JDK-8295803.

src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java line 62:

> 60:     public static void main(String[] args) throws Exception {
> 61:         //disable System.console()
> 62:         System.setProperty("jdk.console", "java.base");

It would probably be more robust to have set on the debuggee command line but what you have is okay, as Console just reads the property rather using the "save properties" from startup.

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

PR: https://git.openjdk.org/jdk20/pull/11

From naoto at openjdk.org  Fri Dec  9 17:36:53 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Dec 2022 17:36:53 GMT
Subject: [jdk20] RFR: 8298425: System.console().readLine() hangs in jshell
In-Reply-To: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
References: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
Message-ID: <YSG9Vwb0CQSzkSoT5ZrvqlmyjXN6hF4kwewrPLh2oNk=.e4ab0115-630d-436c-b6c1-e485bdc51c64@github.com>

On Fri, 9 Dec 2022 13:14:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> After https://bugs.openjdk.org/browse/JDK-8295803, JShell snippets like:
> 
> jshell> System.console().readLine()
> 
> 
> hang, as the JLine console is used, and it cannot correctly read from the console while in the remote agent (due to input/output redirection setup for the agent). Until [JDK-8296454](https://bugs.openjdk.org/browse/JDK-8296454) is resolved, the JLine console should be disabled inside the remote agent.
> 
> As the default console requires an attached terminal, and there is no attached terminal inside the agent, `System.console()` should then return `null` inside the JShell's agent, which was the behavior before JDK-8295803.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/11

From naoto at openjdk.org  Fri Dec  9 17:36:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Dec 2022 17:36:55 GMT
Subject: [jdk20] RFR: 8298425: System.console().readLine() hangs in jshell
In-Reply-To: <nv0RrGKxfE6b8UQsZM93TpWXztCZ6aKhX6i5wwNsaTo=.31cd540d-a4e2-4129-a6f8-fde3b120ef1a@github.com>
References: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
 <nv0RrGKxfE6b8UQsZM93TpWXztCZ6aKhX6i5wwNsaTo=.31cd540d-a4e2-4129-a6f8-fde3b120ef1a@github.com>
Message-ID: <FrqXKU0J7jOm70Lm3qLNyD0ZT6vQDF_MLdkqf2yznEw=.04ca9a93-b700-4cd8-a7aa-5910e6084949@github.com>

On Fri, 9 Dec 2022 15:19:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> After https://bugs.openjdk.org/browse/JDK-8295803, JShell snippets like:
>> 
>> jshell> System.console().readLine()
>> 
>> 
>> hang, as the JLine console is used, and it cannot correctly read from the console while in the remote agent (due to input/output redirection setup for the agent). Until [JDK-8296454](https://bugs.openjdk.org/browse/JDK-8296454) is resolved, the JLine console should be disabled inside the remote agent.
>> 
>> As the default console requires an attached terminal, and there is no attached terminal inside the agent, `System.console()` should then return `null` inside the JShell's agent, which was the behavior before JDK-8295803.
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/RemoteExecutionControl.java line 62:
> 
>> 60:     public static void main(String[] args) throws Exception {
>> 61:         //disable System.console()
>> 62:         System.setProperty("jdk.console", "java.base");
> 
> It would probably be more robust to have set on the debuggee command line but what you have is okay, as Console just reads the property rather using the "save properties" from startup.

Thought of the same thing as Alan mentioned here, but I think it is OK too, as a temporary measure before JDK-8296454 is fixed.

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

PR: https://git.openjdk.org/jdk20/pull/11

From jlahoda at openjdk.org  Mon Dec 12 09:57:32 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 Dec 2022 09:57:32 GMT
Subject: [jdk20] RFR: 8298425: System.console().readLine() hangs in jshell
 [v2]
In-Reply-To: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
References: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
Message-ID: <jmonWAJof1q0AAqMS_nLXnbsskGWijX98JseSPjW2R4=.f7309752-1e56-4f25-8cd6-175f1902519f@github.com>

> After https://bugs.openjdk.org/browse/JDK-8295803, JShell snippets like:
> 
> jshell> System.console().readLine()
> 
> 
> hang, as the JLine console is used, and it cannot correctly read from the console while in the remote agent (due to input/output redirection setup for the agent). Until [JDK-8296454](https://bugs.openjdk.org/browse/JDK-8296454) is resolved, the JLine console should be disabled inside the remote agent.
> 
> As the default console requires an attached terminal, and there is no attached terminal inside the agent, `System.console()` should then return `null` inside the JShell's agent, which was the behavior before JDK-8295803.

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

  Set the jdk.console property on command line.

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/11/files
  - new: https://git.openjdk.org/jdk20/pull/11/files/2404e4e2..e4f32a5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=11&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=11&range=00-01

  Stats: 9 lines in 2 files changed: 6 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/11/head:pull/11

PR: https://git.openjdk.org/jdk20/pull/11

From alanb at openjdk.org  Wed Dec 14 08:43:04 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Dec 2022 08:43:04 GMT
Subject: [jdk20] RFR: 8298425: System.console().readLine() hangs in jshell
 [v2]
In-Reply-To: <jmonWAJof1q0AAqMS_nLXnbsskGWijX98JseSPjW2R4=.f7309752-1e56-4f25-8cd6-175f1902519f@github.com>
References: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
 <jmonWAJof1q0AAqMS_nLXnbsskGWijX98JseSPjW2R4=.f7309752-1e56-4f25-8cd6-175f1902519f@github.com>
Message-ID: <UfKkRc-H40t1qM3kYs11brhb-3PcROSIbo33_WStTas=.93506f08-43a3-4b76-9390-0f3cc548159f@github.com>

On Mon, 12 Dec 2022 09:57:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> After https://bugs.openjdk.org/browse/JDK-8295803, JShell snippets like:
>> 
>> jshell> System.console().readLine()
>> 
>> 
>> hang, as the JLine console is used, and it cannot correctly read from the console while in the remote agent (due to input/output redirection setup for the agent). Until [JDK-8296454](https://bugs.openjdk.org/browse/JDK-8296454) is resolved, the JLine console should be disabled inside the remote agent.
>> 
>> As the default console requires an attached terminal, and there is no attached terminal inside the agent, `System.console()` should then return `null` inside the JShell's agent, which was the behavior before JDK-8295803.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the jdk.console property on command line.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk20/pull/11

From jlahoda at openjdk.org  Wed Dec 14 11:39:51 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Dec 2022 11:39:51 GMT
Subject: [jdk20] Integrated: 8298425: System.console().readLine() hangs in
 jshell
In-Reply-To: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
References: <RgNd07kxiB1IXEpWSGcQ5oiRdOKi3xjOzjYq_SUDN5A=.f6d9018b-e263-441f-8575-f39a838c2e46@github.com>
Message-ID: <kg8lQ5Lf8J9FZeY3tgEb06DyFGbSJkKMP3WgQCtxxEU=.edc464e7-2609-4285-8f85-2d0d3cb34a49@github.com>

On Fri, 9 Dec 2022 13:14:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> After https://bugs.openjdk.org/browse/JDK-8295803, JShell snippets like:
> 
> jshell> System.console().readLine()
> 
> 
> hang, as the JLine console is used, and it cannot correctly read from the console while in the remote agent (due to input/output redirection setup for the agent). Until [JDK-8296454](https://bugs.openjdk.org/browse/JDK-8296454) is resolved, the JLine console should be disabled inside the remote agent.
> 
> As the default console requires an attached terminal, and there is no attached terminal inside the agent, `System.console()` should then return `null` inside the JShell's agent, which was the behavior before JDK-8295803.

This pull request has now been integrated.

Changeset: 9bcdfc42
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/9bcdfc428597e1465c8a014d816ef671420d22df
Stats:     49 lines in 2 files changed: 48 ins; 0 del; 1 mod

8298425: System.console().readLine() hangs in jshell

Reviewed-by: naoto, alanb

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

PR: https://git.openjdk.org/jdk20/pull/11

From jwilhelm at openjdk.org  Wed Dec 14 17:11:21 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 14 Dec 2022 17:11:21 GMT
Subject: RFR: Merge jdk20
Message-ID: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8297235: ZGC: assert(regs[i] != regs[j]) failed: Multiple uses of register: rax
 - 8298649: JFR: RemoteRecordingStream support for checkpoint event sizes beyond u4
 - 8298296: gc/TestFullGCCount.java fails with "System.gc collections miscounted."
 - 8294902: Undefined Behavior in C2 regalloc with null references
 - 8298425: System.console().readLine() hangs in jshell
 - 8298520: C2: assert(found_opaque == res) failed: wrong pattern
 - 8298527: Cygwin's uname -m returns different string than before
 - 8298700: Typo in DocTree comment
 - 8297305: Clarify that javax.lang.model.util.Elements.overrides is irreflexive
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c05dbac3...873a7e3a

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=11678&range=00.0
 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11678&range=00.1

Changes: https://git.openjdk.org/jdk/pull/11678/files
  Stats: 216 lines in 17 files changed: 132 ins; 41 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/11678.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11678/head:pull/11678

PR: https://git.openjdk.org/jdk/pull/11678

From jwilhelm at openjdk.org  Wed Dec 14 21:51:13 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Wed, 14 Dec 2022 21:51:13 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>
References: <MfIrkifsuA1GWjwbhgOaCGmwBUSkPIy0QZnt_yUJoj0=.e5687e4f-5661-4593-8e8d-f061b3bf705f@github.com>
Message-ID: <I5vQumlhaL6cXwuMXUTwTNcFmgSqghC2VhvOpXP-fDk=.a1608d39-d043-4bdd-9711-ff01a50a67fa@github.com>

On Wed, 14 Dec 2022 16:59:54 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: a130c8a6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a130c8a6688fcdda92e0f6295ec06f1591382328
Stats:     216 lines in 17 files changed: 132 ins; 41 del; 43 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/11678