From jlahoda at openjdk.org  Wed May  1 12:23:40 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 May 2024 12:23:40 GMT
Subject: RFR: 8328481: Implement Module Imports [v13]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <p7IXqBQTq14EQ2O2Js-24jO8vJ7Ce2ijJGsu4SBijFQ=.365acb11-c8af-41e1-8767-ff62ed1443c4@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge branch 'master' into module-imports
 - Fixing test on Windows (2).
 - Fixing Imports test on Windows.
 - Adding test for ImportTree.isModule, as suggested.
 - Reflecting review feedback - improving the 'module (current) does not read (target).
 - Updating JEP number and caption.
 - Fixing ListModuleDeps test.
 - Cleanup.
 - Merge branch 'master' into module-imports
 - Including current module name as suggested.
 - ... and 18 more: https://git.openjdk.org/jdk/compare/4e5c25ee...43a1e0f6

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

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=12
  Stats: 1343 lines in 31 files changed: 1268 ins; 17 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From rriggs at openjdk.org  Wed May  1 17:13:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 1 May 2024 17:13:53 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
Message-ID: <8hJNdHFB4b_BNB3gv6-5zX5TIfr8IC_otcbtpu0QPxE=.b66ab258-58b4-48af-a9b3-533657e0c2c6@github.com>

On Mon, 29 Apr 2024 23:22:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

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

> 87:     @Override
> 88:     public Console format(String format, Object ... args) {
> 89:         return format(Locale.getDefault(Locale.Category.FORMAT), format, args);

Given the number of calls to Locale.getDefault(Locale.Category.FORMAT) it might be worthwhile to cache that in the Proxying Console or in the JdkConsoleImpl.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1586523255

From naoto at openjdk.org  Wed May  1 17:42:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 May 2024 17:42:58 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <8hJNdHFB4b_BNB3gv6-5zX5TIfr8IC_otcbtpu0QPxE=.b66ab258-58b4-48af-a9b3-533657e0c2c6@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
 <8hJNdHFB4b_BNB3gv6-5zX5TIfr8IC_otcbtpu0QPxE=.b66ab258-58b4-48af-a9b3-533657e0c2c6@github.com>
Message-ID: <k_WUc4k2xFD5fENgfaJPLNpLZO7f_U8VNo96tQgvjd0=.7ced3a14-c13a-4635-8cdb-f1512912b2ba@github.com>

On Wed, 1 May 2024 17:10:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed review comments
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 89:
> 
>> 87:     @Override
>> 88:     public Console format(String format, Object ... args) {
>> 89:         return format(Locale.getDefault(Locale.Category.FORMAT), format, args);
> 
> Given the number of calls to Locale.getDefault(Locale.Category.FORMAT) it might be worthwhile to cache that in the Proxying Console or in the JdkConsoleImpl.

Initially, I thought about it but did not cache it here because it is cached in the `Locale` class, and the call returns the cached value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18923#discussion_r1586554554

From jlahoda at openjdk.org  Wed May  1 18:35:55 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 May 2024 18:35:55 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v2]
In-Reply-To: <AgPIsLMYyLc6_iCfo4b-tiVW6MMEsPxhfQeGgH4ocxM=.81a948e8-e20a-496a-8054-b0fa5e7da998@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <eMk7DeAISMbeK9czK6rvnqYruYvSwit6FYmig3whCsQ=.0449e2f1-4009-40da-998d-134f44dd279b@github.com>
 <AgPIsLMYyLc6_iCfo4b-tiVW6MMEsPxhfQeGgH4ocxM=.81a948e8-e20a-496a-8054-b0fa5e7da998@github.com>
Message-ID: <kDfhfAobptsuCc5K26QBOK3NrRqmLlrBIUEdNrWF3aw=.848df900-667d-453a-a1f3-b39b2010948e@github.com>

On Mon, 29 Apr 2024 18:41:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good to me. Left some minor suggestions. BTW, should we file an issue at the `JLine` project, not to redirect to stderr, or suggest a new config (sorry if it has already been taken care of)?

The code to choose the output stream is quite elaborate, so I assume that is intentional. For new versions of JLine, the `systemOutput(SystemOutput.SysOut)` forces the use of stdout, however, so the patch to JLine itself will not be needed anymore after we upgrade.

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

PR Comment: https://git.openjdk.org/jdk/pull/18996#issuecomment-2088894660

From naoto at openjdk.org  Wed May  1 18:45:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 1 May 2024 18:45:52 GMT
Subject: RFR: 8330998: System.console() writes to stderr when stdout is
 redirected [v3]
In-Reply-To: <bJ99HAH1H96JfGviZb0bcGd5sKqTd0Pe06mgRxcG4Cc=.f1e8001f-1302-4385-be67-7686609ffa61@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
 <bJ99HAH1H96JfGviZb0bcGd5sKqTd0Pe06mgRxcG4Cc=.f1e8001f-1302-4385-be67-7686609ffa61@github.com>
Message-ID: <MFV0jGRWediMw8brXec7tHAZlipgzDQlF5d0RckFdUk=.3c66304e-15da-4487-89a8-0d9cca2d1f56@github.com>

On Tue, 30 Apr 2024 15:02:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> public class ConsoleTest {
>>     public static void main(String... args) {
>>         System.console().printf("Hello!");
>>     }
>> }
>> 
>> 
>> When run as:
>> 
>> $ java ConsoleTest.java >/dev/null
>> 
>> 
>> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
>> 
>> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
>> 
>> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting test, as suggested.

Looks good!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18996#pullrequestreview-2034202479

From jlahoda at openjdk.org  Fri May  3 07:21:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 May 2024 07:21:27 GMT
Subject: RFR: 8327476: Upgrade JLine to 3.25.1 [v5]
In-Reply-To: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
References: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
Message-ID: <ISHgSPccPJO0QusvPNM6gLBVBNGCBhFENaYa7TCJF6w=.45a8b5dc-ab7f-4f77-864f-13bf2d38a742@github.com>

> This is a patch that:
> a) upgrades the JLine inside the JDK to 3.25.1
> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend
> 
> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are:
> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945
> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily
> 
> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects:
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal
> the patch is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff
> 
> I've also cleaned the patch a little removing most of the changes for the rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Fixing test.
 - Cleanup.
 - Upgrade to 3.26.1
 - Merge branch 'master' into jline-upgrade-3.25.1
 - Merge branch 'master' into jline-upgrade-3.25.1
 - Merge branch 'master' into jline-upgrade-3.25.1
 - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1
 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
 - Apply suggestions from code review
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1
 - ... and 20 more: https://git.openjdk.org/jdk/compare/130f71ca...01f95c42

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

Changes: https://git.openjdk.org/jdk/pull/18142/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=04
  Stats: 13181 lines in 144 files changed: 5785 ins; 5349 del; 2047 mod
  Patch: https://git.openjdk.org/jdk/pull/18142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142

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

From jlahoda at openjdk.org  Fri May  3 07:27:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 May 2024 07:27:09 GMT
Subject: RFR: 8327476: Upgrade JLine to 3.26.1 [v6]
In-Reply-To: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
References: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
Message-ID: <Si8oUq0us09toKCyYhg6Finfzc0krMs3Qvp_705WIBg=.1fe662f8-bf9c-4c31-92c3-e620b53123f8@github.com>

> This is a patch that:
> a) upgrades the JLine inside the JDK to 3.25.1
> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend
> 
> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are:
> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945
> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily
> 
> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects:
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal
> the patch is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff
> 
> I've also cleaned the patch a little removing most of the changes for the rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff

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

  Removing trailing whitespace.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18142/files
  - new: https://git.openjdk.org/jdk/pull/18142/files/01f95c42..9f6509a9

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

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

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

From jlahoda at openjdk.org  Fri May  3 07:27:12 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 May 2024 07:27:12 GMT
Subject: RFR: 8327476: Upgrade JLine to 3.26.1 [v5]
In-Reply-To: <ISHgSPccPJO0QusvPNM6gLBVBNGCBhFENaYa7TCJF6w=.45a8b5dc-ab7f-4f77-864f-13bf2d38a742@github.com>
References: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
 <ISHgSPccPJO0QusvPNM6gLBVBNGCBhFENaYa7TCJF6w=.45a8b5dc-ab7f-4f77-864f-13bf2d38a742@github.com>
Message-ID: <usGBmNMVx3SH5fVoNnw--bksiPCbK9I_LEbnkzgQ9ps=.9bcd749a-c8bb-48bd-8cfc-7e582f3ea66e@github.com>

On Fri, 3 May 2024 07:21:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch that:
>> a) upgrades the JLine inside the JDK to 3.25.1
>> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend
>> 
>> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are:
>> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945
>> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily
>> 
>> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects:
>> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader
>> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm
>> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal
>> the patch is here:
>> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff
>> 
>> I've also cleaned the patch a little removing most of the changes for the rename. The result is here:
>> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - Fixing test.
>  - Cleanup.
>  - Upgrade to 3.26.1
>  - Merge branch 'master' into jline-upgrade-3.25.1
>  - Merge branch 'master' into jline-upgrade-3.25.1
>  - Merge branch 'master' into jline-upgrade-3.25.1
>  - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1
>  - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
>  - Apply suggestions from code review
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/130f71ca...01f95c42

Update: since JLine 3.26.1 was release, I tried to upgrade to that directly. I made a diff of the relevant files between JLine 3.25.1 and 3.26.1, and applied that diff to our code. Some additional cleanup was done as well, as suggested by Magnus.

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

PR Comment: https://git.openjdk.org/jdk/pull/18142#issuecomment-2092453108

From jlahoda at openjdk.org  Fri May  3 10:17:08 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 May 2024 10:17:08 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
Message-ID: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>

When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:

System.console().readLine("%%s");


will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

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

Depends on: https://git.openjdk.org/jdk/pull/18996

Commit messages:
 - 8331535: Incorrect prompt for Console.readLine

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

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

From prappo at openjdk.org  Fri May  3 11:24:54 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 May 2024 11:24:54 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>

On Fri, 3 May 2024 10:11:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

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

> 99:             try {
> 100:                 initJLineIfNeeded();
> 101:                 return jline.readLine(fmt.formatted(args).replace("%", "%%"));

I understand that [JLine interprets `%` in a prompt](https://github.com/openjdk/jdk/blob/4ed38f5ad5f822ab948257ed39717ea919fd32ed/src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java#L4050), but are the interpretation rules documented on JLine GitHub page or elsewhere?

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

> 114:             try {
> 115:                 initJLineIfNeeded();
> 116:                 return jline.readLine(fmt.formatted(args).replace("%", "%%"), '\0')

I find `'\0'` more cryptic and confusing than `(char) 0`, but okay. (Had to re-read https://docs.oracle.com/javase/specs/jls/se22/html/jls-3.html#jls-EscapeSequence)

test/jdk/jdk/internal/jline/JLineConsoleProviderTest.java line 27:

> 25:  * @test
> 26:  * @bug 8331535
> 27:  * @summary Verify the jdk.internal.le's console provider works properly.

There's a hidden assumption in this test below that the _default_ console is `jdk.internal.le`. Is there any way to assert that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589074603
PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589065719
PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589067927

From ihse at openjdk.org  Fri May  3 15:02:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 3 May 2024 15:02:54 GMT
Subject: RFR: 8327476: Upgrade JLine to 3.26.1 [v6]
In-Reply-To: <Si8oUq0us09toKCyYhg6Finfzc0krMs3Qvp_705WIBg=.1fe662f8-bf9c-4c31-92c3-e620b53123f8@github.com>
References: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
 <Si8oUq0us09toKCyYhg6Finfzc0krMs3Qvp_705WIBg=.1fe662f8-bf9c-4c31-92c3-e620b53123f8@github.com>
Message-ID: <Zazd2yUHHfyxQVtx5gElE2cCVDdp2zuGtqSLtwcZKiQ=.1866358e-c274-4bcd-8711-a4c254676bd1@github.com>

On Fri, 3 May 2024 07:27:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch that:
>> a) upgrades the JLine inside the JDK to 3.25.1
>> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend
>> 
>> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are:
>> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945
>> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily
>> 
>> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects:
>> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader
>> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm
>> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal
>> the patch is here:
>> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff
>> 
>> I've also cleaned the patch a little removing most of the changes for the rename. The result is here:
>> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing trailing whitespace.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18142#pullrequestreview-2038354269

From naoto at openjdk.org  Fri May  3 17:10:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 17:10:54 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
Message-ID: <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>

On Fri, 3 May 2024 11:12:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> test/jdk/jdk/internal/jline/JLineConsoleProviderTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8331535
>> 27:  * @summary Verify the jdk.internal.le's console provider works properly.
> 
> There's a hidden assumption in this test below that the _default_ console is `jdk.internal.le`. Is there any way to assert that?

Or maybe we could explicitly specify `-Djdk.console=jdk.internal.le` to the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589477775

From prappo at openjdk.org  Fri May  3 18:54:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 May 2024 18:54:52 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
Message-ID: <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>

On Fri, 3 May 2024 17:07:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Or maybe we could explicitly specify `-Djdk.console=jdk.internal.le` to the test.

We could do that, or we could replace `jdk.internal.le` with "default" in the summary.

Ideally, we should have separate tests that make sure that jdk.internal.le is the default impl. We should also test this behaviour (i.e. % interpretation) on jdk.internal.io Console impl. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589620826

From naoto at openjdk.org  Fri May  3 19:05:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 3 May 2024 19:05:54 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
Message-ID: <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>

On Fri, 3 May 2024 18:52:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Ideally, we should have separate tests that make sure that jdk.internal.le is the default impl.

We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)

> We should also test this behaviour (i.e. % interpretation) on jdk.internal.io Console impl.

Yeah, that would be helpful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589629655

From rriggs at openjdk.org  Fri May  3 19:54:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 May 2024 19:54:54 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v2]
In-Reply-To: <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <3PG6UCpNxIV2SSDuHcQ66RhUisK1MNtWT-IX68iXuEc=.c3f3e3b5-988f-4178-8ec7-992b8de6b8ca@github.com>
Message-ID: <9mG8LRGPDCyJUH6ftDQ1w9nNA23pfj1HVtLFksbI1vo=.af217a17-1a9e-4375-9921-9e0cd448cccb@github.com>

On Mon, 29 Apr 2024 23:22:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18923#pullrequestreview-2038907502

From prappo at openjdk.org  Fri May  3 22:01:57 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 May 2024 22:01:57 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
 <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
Message-ID: <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>

On Fri, 3 May 2024 19:02:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>

Good; then here we should indeed specify `-Djdk.console=jdk.internal.le`. Initially, I suggested an alternative wording (i.e. "default"), but that's inappropriate. After all, the test in question resides in `test/jdk/jdk/internal/jline`. So it only makes sense that it tests that concrete implementation. 

> Yeah, that would be helpful.
>

I filed a bug: https://bugs.openjdk.org/browse/JDK-8331681

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1589756489

From duke at openjdk.org  Sat May  4 19:25:06 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sat, 4 May 2024 19:25:06 GMT
Subject: RFR: 8129418: JShell: better highlighting of errors in imports on
 demand
Message-ID: <JvdpMuEPieuMJkI27_pgiFYxoI-8DyP26p0h_q46NLU=.2273a069-2d0f-4542-a962-986d3c6ad503@github.com>

When Type-Import-on-Demand fails, we now point the position of the first incorrect PackageOrTypeName which clearly isn't package, a class,or an interface.

old behavior:

|  Welcome to JShell -- Version 22.0.1
|  For an introduction type: /help intro

jshell> import unknown.*;
|  Error:
|  package unknown does not exist
|  import unknown.*;
|  ^

New behavior:

|  Welcome to JShell -- Version 23-internal
|  For an introduction type: /help intro

jshell> import unknown.*;
|  Error:
|  package unknown does not exist
|  import unknown.*;
|         ^-----^



jshell> import unknown.unknown.unknown.*;
|  Error:
|  package unknown.unknown.unknown does not exist
|  import unknown.unknown.unknown.*;
|         ^---------------------^

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

Commit messages:
 - Pass a `DiagnosticPosition` with a start/position/end to the logging method rather than an int
 - When Type-Import-on-Demand fails, log the position of the first PackageOrTypeName

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

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

From jlahoda at openjdk.org  Sat May  4 19:25:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Sat, 4 May 2024 19:25:06 GMT
Subject: RFR: 8129418: JShell: better highlighting of errors in imports on
 demand
In-Reply-To: <JvdpMuEPieuMJkI27_pgiFYxoI-8DyP26p0h_q46NLU=.2273a069-2d0f-4542-a962-986d3c6ad503@github.com>
References: <JvdpMuEPieuMJkI27_pgiFYxoI-8DyP26p0h_q46NLU=.2273a069-2d0f-4542-a962-986d3c6ad503@github.com>
Message-ID: <vSri6yPQ5uNG6d0RR_QrCloqY9g2BKjM5uq7UhxbcCI=.6b00cef3-29d9-49ff-931b-e31784f799ab@github.com>

On Thu, 2 May 2024 23:42:38 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> When Type-Import-on-Demand fails, we now point the position of the first incorrect PackageOrTypeName which clearly isn't package, a class,or an interface.
> 
> old behavior:
> 
> |  Welcome to JShell -- Version 22.0.1
> |  For an introduction type: /help intro
> 
> jshell> import unknown.*;
> |  Error:
> |  package unknown does not exist
> |  import unknown.*;
> |  ^
> 
> New behavior:
> 
> |  Welcome to JShell -- Version 23-internal
> |  For an introduction type: /help intro
> 
> jshell> import unknown.*;
> |  Error:
> |  package unknown does not exist
> |  import unknown.*;
> |         ^-----^
> 
> 
> 
> jshell> import unknown.unknown.unknown.*;
> |  Error:
> |  package unknown.unknown.unknown does not exist
> |  import unknown.unknown.unknown.*;
> |         ^---------------------^

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4428:

> 4426:                 if (tsym.kind == PCK && tsym.members().isEmpty() &&
> 4427:                     !(Feature.IMPORT_ON_DEMAND_OBSERVABLE_PACKAGES.allowedInSource(source) && tsym.exists())) {
> 4428:                     log.error(DiagnosticFlag.RESOLVE_ERROR, imp.qualid.selected.pos, Errors.DoesntExist(tsym));

I would suggest to use `.pos()`, instead of `.pos`. The former returns a `DiagnosticPosition`, with start/end/preferred positions, while the later just an integer. I.e. in JShell, the former will do:

jshell> import unknown.unknown.unknown.*;
|  Error:
|  package unknown.unknown.unknown does not exist
|  import unknown.unknown.unknown.*;
|         ^---------------------^


while the latter will do:

jshell> import unknown.unknown.unknown.*;
|  Error:
|  package unknown.unknown.unknown does not exist
|  import unknown.unknown.unknown.*;
|                        ^

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19073#discussion_r1588861114

From duke at openjdk.org  Sat May  4 19:25:06 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sat, 4 May 2024 19:25:06 GMT
Subject: RFR: 8129418: JShell: better highlighting of errors in imports on
 demand
In-Reply-To: <vSri6yPQ5uNG6d0RR_QrCloqY9g2BKjM5uq7UhxbcCI=.6b00cef3-29d9-49ff-931b-e31784f799ab@github.com>
References: <JvdpMuEPieuMJkI27_pgiFYxoI-8DyP26p0h_q46NLU=.2273a069-2d0f-4542-a962-986d3c6ad503@github.com>
 <vSri6yPQ5uNG6d0RR_QrCloqY9g2BKjM5uq7UhxbcCI=.6b00cef3-29d9-49ff-931b-e31784f799ab@github.com>
Message-ID: <RbgqUWK9RUl1eJdA2dL39yGs_4pclSTcGYnRf8PIggM=.35bf5c6f-d028-48a6-b267-3d0e1abfa3a6@github.com>

On Fri, 3 May 2024 07:49:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When Type-Import-on-Demand fails, we now point the position of the first incorrect PackageOrTypeName which clearly isn't package, a class,or an interface.
>> 
>> old behavior:
>> 
>> |  Welcome to JShell -- Version 22.0.1
>> |  For an introduction type: /help intro
>> 
>> jshell> import unknown.*;
>> |  Error:
>> |  package unknown does not exist
>> |  import unknown.*;
>> |  ^
>> 
>> New behavior:
>> 
>> |  Welcome to JShell -- Version 23-internal
>> |  For an introduction type: /help intro
>> 
>> jshell> import unknown.*;
>> |  Error:
>> |  package unknown does not exist
>> |  import unknown.*;
>> |         ^-----^
>> 
>> 
>> 
>> jshell> import unknown.unknown.unknown.*;
>> |  Error:
>> |  package unknown.unknown.unknown does not exist
>> |  import unknown.unknown.unknown.*;
>> |         ^---------------------^
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4428:
> 
>> 4426:                 if (tsym.kind == PCK && tsym.members().isEmpty() &&
>> 4427:                     !(Feature.IMPORT_ON_DEMAND_OBSERVABLE_PACKAGES.allowedInSource(source) && tsym.exists())) {
>> 4428:                     log.error(DiagnosticFlag.RESOLVE_ERROR, imp.qualid.selected.pos, Errors.DoesntExist(tsym));
> 
> I would suggest to use `.pos()`, instead of `.pos`. The former returns a `DiagnosticPosition`, with start/end/preferred positions, while the later just an integer. I.e. in JShell, the former will do:
> 
> jshell> import unknown.unknown.unknown.*;
> |  Error:
> |  package unknown.unknown.unknown does not exist
> |  import unknown.unknown.unknown.*;
> |         ^---------------------^
> 
> 
> while the latter will do:
> 
> jshell> import unknown.unknown.unknown.*;
> |  Error:
> |  package unknown.unknown.unknown does not exist
> |  import unknown.unknown.unknown.*;
> |                        ^

Fixed in [c01e851](https://github.com/openjdk/jdk/pull/19073/commits/c01e851fdfb95977a1898c7fabee119ee230ab83), thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19073#discussion_r1590096705

From jlahoda at openjdk.org  Mon May  6 05:52:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 05:52:06 GMT
Subject: Integrated: 8328481: Implement JEP 476: Module Import Declarations
 (Preview)
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <L6AP_Ej42zAwyq67lrOR90Fc7sPJ0d09K694ERkaqa4=.7e232a9b-887f-4d83-b10d-a98b0d38f75d@github.com>

On Thu, 4 Apr 2024 07:30:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

This pull request has now been integrated.

Changeset: f2c4a413
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2c4a41304d4fe984b79792cb3be460d7026e812
Stats:     1343 lines in 31 files changed: 1268 ins; 17 del; 58 mod

8328481: Implement JEP 476: Module Import Declarations (Preview)

Co-authored-by: Jim Laskey <jlaskey at openjdk.org>
Reviewed-by: mcimadamore, vromero

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

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

From jlahoda at openjdk.org  Mon May  6 06:05:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 06:05:00 GMT
Subject: Integrated: 8330998: System.console() writes to stderr when stdout is
 redirected
In-Reply-To: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
References: <A8XxdrFyHsuO_Kj27Y9eLMSgYnhvYW9ZKzs_sVJnTDM=.8a53eac4-2d84-4264-a591-8872071ecda1@github.com>
Message-ID: <5fVRZuuPOddKBol6s6EsI6iIzP6hRdZ69GC_Y-0ttaU=.500e4ed6-e550-42d7-b83e-53915ad360cc@github.com>

On Mon, 29 Apr 2024 11:44:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class ConsoleTest {
>     public static void main(String... args) {
>         System.console().printf("Hello!");
>     }
> }
> 
> 
> When run as:
> 
> $ java ConsoleTest.java >/dev/null
> 
> 
> it prints `Hello!` to stderr, instead of to stdout (where it would be redirected).
> 
> The proposed fix is to simply force the use of stdout. Sadly, this cannot be done solely using JLine configuration, we actually need to change the JLine's code for that.
> 
> The most tricky part is a test. There are two sub-tests, one effectively testing a case where all of stdin/out/err are redirected, the other is attempting to test the case where stdin is attached to a terminal, while stdout is redirected. The second sub-test using a native functions to create a pty and to attach to it, and should run in a separate VM, as it leaves the VM attached to the terminal.

This pull request has now been integrated.

Changeset: f1509e00
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1509e007d1538acfb1749f7fafc56be2affd2e6
Stats:     183 lines in 3 files changed: 180 ins; 0 del; 3 mod

8330998: System.console() writes to stderr when stdout is redirected

Reviewed-by: naoto

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

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

From jlahoda at openjdk.org  Mon May  6 06:08:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 06:08:25 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <n2hVZsDk5ut0paY93n_fssp8by37H3qBUotJuRBj69c=.040aa884-0cfe-4990-a32c-c83de9de8e42@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

Jan Lahoda 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19081/files
  - new: https://git.openjdk.org/jdk/pull/19081/files/58cbd42e..58cbd42e

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

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

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

From jlahoda at openjdk.org  Mon May  6 15:45:54 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 15:45:54 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
Message-ID: <iAaeLI0jUBs9VDdPufvV8lNXsrhWdXv7i-FNW60OqOc=.5703f0b4-54e7-4f72-8f44-0c79f21b3fbb@github.com>

On Fri, 3 May 2024 11:20:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jan Lahoda 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.
>
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 101:
> 
>> 99:             try {
>> 100:                 initJLineIfNeeded();
>> 101:                 return jline.readLine(fmt.formatted(args).replace("%", "%%"));
> 
> I understand that [JLine interprets `%` in a prompt](https://github.com/openjdk/jdk/blob/4ed38f5ad5f822ab948257ed39717ea919fd32ed/src/jdk.internal.le/share/classes/jdk/internal/org/jline/reader/impl/LineReaderImpl.java#L4050), but are the interpretation rules documented on JLine GitHub page or elsewhere?

There's a description in the javadoc:
https://www.javadoc.io/doc/org.jline/jline/latest/org/jline/reader/LineReader.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591196087

From jlahoda at openjdk.org  Mon May  6 16:09:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 16:09:19 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v3]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <ERRduhiHCZbzJHciDdzX27mVGZdvupV65b2rdFSI6U0=.e8ba81cb-9ff1-4d7e-b4af-00db8c2381de@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

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

 - Adjusting test as suggested.
 - Merge branch 'master' into JDK-8331535
 - 8331535: Incorrect prompt for Console.readLine
 - Fixing test.
 - Attempting to stabilize the test.
 - Improving test to really test the redirect while stdin is connected to a terminal.
 - Fixing typo.
 - 8330998: System.console() writes to stderr when stdout is redirected

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

Changes: https://git.openjdk.org/jdk/pull/19081/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19081&range=02
  Stats: 210 lines in 3 files changed: 208 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19081/head:pull/19081

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

From jlahoda at openjdk.org  Mon May  6 16:09:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 6 May 2024 16:09:19 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
 <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
 <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>
Message-ID: <WY2eBTY7aMvu7EhYydvrXg32tOZBTbih14XsRiK7ydI=.1b7b087e-4879-462c-83b0-ee270b1f08b5@github.com>

On Fri, 3 May 2024 21:59:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> Ideally, we should have separate tests that make sure that jdk.internal.le is the default impl.
>> 
>> We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>> 
>>> We should also test this behaviour (i.e. % interpretation) on jdk.internal.io Console impl.
>> 
>> Yeah, that would be helpful.
>
>> We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>>
> 
> Good; then here we should indeed specify `-Djdk.console=jdk.internal.le`. Initially, I suggested an alternative wording (i.e. "default"), but that's inappropriate. After all, the test in question resides in `test/jdk/jdk/internal/jline`. So it only makes sense that it tests that concrete implementation. 
> 
>> Yeah, that would be helpful.
>>
> 
> I filed a bug: https://bugs.openjdk.org/browse/JDK-8331681

Thanks. I've added `-Djdk.console=jdk.internal.le`, and also added a test for the `java.base`'s console: `test/jdk/java/io/Console/ConsolePromptTest.java`. I can easily remove the latter if this is not a reasonable form. Or I can fix it as needed. Please let me know.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591228737

From naoto at openjdk.org  Mon May  6 17:02:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 17:02:56 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v3]
In-Reply-To: <ERRduhiHCZbzJHciDdzX27mVGZdvupV65b2rdFSI6U0=.e8ba81cb-9ff1-4d7e-b4af-00db8c2381de@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <ERRduhiHCZbzJHciDdzX27mVGZdvupV65b2rdFSI6U0=.e8ba81cb-9ff1-4d7e-b4af-00db8c2381de@github.com>
Message-ID: <GpFSxVw4pzOmBtUS0m7Jqh6R5ZI2HkTw9Em9u83wRjo=.e80f387e-c9fb-4c22-bc83-5bf52acfff5d@github.com>

On Mon, 6 May 2024 16:09:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Adjusting test as suggested.
>  - Merge branch 'master' into JDK-8331535
>  - 8331535: Incorrect prompt for Console.readLine
>  - Fixing test.
>  - Attempting to stabilize the test.
>  - Improving test to really test the redirect while stdin is connected to a terminal.
>  - Fixing typo.
>  - 8330998: System.console() writes to stderr when stdout is redirected

Looks good

test/jdk/java/io/Console/ConsolePromptTest.java line 29:

> 27:  * @summary Verify the java.base's console provider handles the prompt correctly.
> 28:  * @library /test/lib
> 29:  * @run main/othervm --limit-modules java.base ConsolePromptTest

It would be helpful if we do another run with `-Djdk.console=java.base` too.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19081#pullrequestreview-2041252866
PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591300205

From naoto at openjdk.org  Mon May  6 17:02:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 17:02:57 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <WY2eBTY7aMvu7EhYydvrXg32tOZBTbih14XsRiK7ydI=.1b7b087e-4879-462c-83b0-ee270b1f08b5@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
 <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
 <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>
 <WY2eBTY7aMvu7EhYydvrXg32tOZBTbih14XsRiK7ydI=.1b7b087e-4879-462c-83b0-ee270b1f08b5@github.com>
Message-ID: <tQQpQMy6HcuNPLk-4ifOXV4XCZVkKHFbYdW8x45TDNQ=.9b0988a9-7670-4416-a008-2e5fc7bf5057@github.com>

On Mon, 6 May 2024 16:05:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> We have a test that checks if `System.console()` returns the correct Console (or null) from the expected module (`test/jdk/java/io/Console/ModuleSelectionTest.java`)
>>>
>> 
>> Good; then here we should indeed specify `-Djdk.console=jdk.internal.le`. Initially, I suggested an alternative wording (i.e. "default"), but that's inappropriate. After all, the test in question resides in `test/jdk/jdk/internal/jline`. So it only makes sense that it tests that concrete implementation. 
>> 
>>> Yeah, that would be helpful.
>>>
>> 
>> I filed a bug: https://bugs.openjdk.org/browse/JDK-8331681
>
> Thanks. I've added `-Djdk.console=jdk.internal.le`, and also added a test for the `java.base`'s console: `test/jdk/java/io/Console/ConsolePromptTest.java`. I can easily remove the latter if this is not a reasonable form. Or I can fix it as needed. Please let me know.
> 
> Thanks.

For the latter, since you are already at it, I just reassigned the bug to you ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591302360

From prappo at openjdk.org  Mon May  6 18:53:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 May 2024 18:53:52 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v2]
In-Reply-To: <tQQpQMy6HcuNPLk-4ifOXV4XCZVkKHFbYdW8x45TDNQ=.9b0988a9-7670-4416-a008-2e5fc7bf5057@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <3m2vXDnx0X_2f3aJxt61yStX_9jyuzIjjhhpgGBmm0Q=.9597c9c6-586a-4ad1-ad91-2a7fa779a427@github.com>
 <hAmrGczr1ChxLcKOeV62E5Gwa2nMiAW0NqMS9JyaADA=.a7d37721-9fd0-46cc-a8d5-2b5ac5b43c29@github.com>
 <ZyGQrhrrVBjBxbOaTmSMhIdtUm6AgvSE9U3Sg8tBGOM=.651480e9-34d1-4517-baab-a6ddefb16fe5@github.com>
 <-1kM8rbTDNczIqktUIsWDXpreQLTJvqSkEINSVdLJ6g=.3ab5d6c5-dde6-4204-aed2-c4d62b5024ef@github.com>
 <01jKa1Vle6swIlyHyAGC9RLlkvKMABNV4gARTNkctb0=.db05c58c-cae1-4860-a41f-542d55b58671@github.com>
 <WY2eBTY7aMvu7EhYydvrXg32tOZBTbih14XsRiK7ydI=.1b7b087e-4879-462c-83b0-ee270b1f08b5@github.com>
 <tQQpQMy6HcuNPLk-4ifOXV4XCZVkKHFbYdW8x45TDNQ=.9b0988a9-7670-4416-a008-2e5fc7bf5057@github.com>
Message-ID: <R6pynt0VTor0C4QwhVvr-Fvw7MLsxD69ATMd3mXCjAw=.7dcb4e0a-f54d-4a06-a197-2fcb38bbfb8e@github.com>

On Mon, 6 May 2024 16:59:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> For the latter, since you are already at it, I just reassigned the bug to you ?

@lahodaj, since a test for 8331681 is added to this PR, I'd suggest you do this: `/issue add 8331681`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1591423527

From naoto at openjdk.org  Mon May  6 20:01:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 6 May 2024 20:01:14 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v3]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <ayIrpchOReTkcPND-iRPjbSXtKlqHyamDsuEQGSbYnU=.66710878-eedd-435c-b2a4-42bdcad9ca39@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

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 six additional commits since the last revision:

 - Addresses a CSR review comment
 - Merge branch 'master' into JDK-8330276-Console-with-explicit-Locale
 - Addressed review comments
 - Not using System.err
 - spacing
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/7884cfe3..29ff6063

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

  Stats: 33162 lines in 1907 files changed: 14282 ins; 12249 del; 6631 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

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

From prappo at openjdk.org  Mon May  6 21:50:37 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 May 2024 21:50:37 GMT
Subject: RFR: 8305457: Implement java.io.IO
Message-ID: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>

Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].

This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].

[Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
[draft PR]: https://github.com/openjdk/jdk/pull/18921

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/19112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305457
  Stats: 664 lines in 13 files changed: 660 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From liach at openjdk.org  Tue May  7 01:28:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 7 May 2024 01:28:59 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>

On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

src/java.base/share/classes/java/io/IO.java line 41:

> 39:  */
> 40: @PreviewFeature(feature = PreviewFeature.Feature.IMPLICIT_CLASSES)
> 41: public class IO {

Should this be final?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591707684

From darcy at openjdk.org  Tue May  7 02:56:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 May 2024 02:56:54 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
Message-ID: <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>

On Tue, 7 May 2024 01:26:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should this be final?

With only the private constructor, it doesn't matter too much in practice, but an explicit `final` would be good documentation if that is the intent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591751257

From forax at openjdk.org  Tue May  7 05:55:55 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 7 May 2024 05:55:55 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>

On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Otherwise looks good.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 74:

> 72: 
> 73:     @Override
> 74:     public String readln(String prompt) {

this code can be simplified using an early return (and the body of the try/catch can be reduced so it is more clear which statement can cause the IOException)

        synchronized (writeLock) {
            synchronized(readLock) {
                if (!prompt.isEmpty()) {
                    pw.print(prompt);
                    pw.flush(); // automatic flushing does not cover print
                }
               char[] array;
                try {
                    array = readline(false);
                } catch (IOException x) {
                    throw new IOError(x);
                }
                if (array != null) {
                    return new String(array);
                }
            }
        }
        return null;

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

> 86:         @Override
> 87:         public JdkConsole println(Object obj) {
> 88:             writer().println(obj);

the result of 'writer()' can be stored in a local variable (printing code are not JITed as often as the rest of the codes)

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

PR Comment: https://git.openjdk.org/jdk/pull/19112#issuecomment-2097502361
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591846059
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591847579

From jlahoda at openjdk.org  Tue May  7 07:13:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 7 May 2024 07:13:23 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v4]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <odGBY-01VvMY90f3GM90D6SDIFkm4DQPE0C1_5SAJGk=.e2fba76c-9946-4abc-8c83-cd34d6045735@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

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

  Adding another test run with -Djdk.console=java.base, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19081/files
  - new: https://git.openjdk.org/jdk/pull/19081/files/05592871..a138981e

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

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

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

From jlahoda at openjdk.org  Tue May  7 09:19:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 7 May 2024 09:19:15 GMT
Subject: RFR: 8327476: Upgrade JLine to 3.26.1 [v7]
In-Reply-To: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
References: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
Message-ID: <dHwipqjS-Wmg2AN98H4n7gcX9N5oPpv-GxTOkTkYVso=.592a0544-cc10-4bf3-9b90-7621b8cffbd0@github.com>

> This is a patch that:
> a) upgrades the JLine inside the JDK to 3.25.1
> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend
> 
> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are:
> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945
> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily
> 
> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects:
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal
> the patch is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff
> 
> I've also cleaned the patch a little removing most of the changes for the rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into jline-upgrade-3.25.1
 - Removing trailing whitespace.
 - Fixing test.
 - Cleanup.
 - Upgrade to 3.26.1
 - Merge branch 'master' into jline-upgrade-3.25.1
 - Merge branch 'master' into jline-upgrade-3.25.1
 - Merge branch 'master' into jline-upgrade-3.25.1
 - Merge branch 'native-access-modules1' into jline-upgrade-3.25.1
 - Merge remote-tracking branch 'origin/native-access-modules1' into native-access-modules1
 - ... and 22 more: https://git.openjdk.org/jdk/compare/23a72a1f...5d900a6e

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

Changes: https://git.openjdk.org/jdk/pull/18142/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18142&range=06
  Stats: 13181 lines in 144 files changed: 5784 ins; 5349 del; 2048 mod
  Patch: https://git.openjdk.org/jdk/pull/18142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18142/head:pull/18142

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

From prappo at openjdk.org  Tue May  7 11:04:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 11:04:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
Message-ID: <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>

On Tue, 7 May 2024 05:49:58 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 74:
> 
>> 72: 
>> 73:     @Override
>> 74:     public String readln(String prompt) {
> 
> this code can be simplified using an early return (and the body of the try/catch can be reduced so it is more clear which statement can cause the IOException)
> 
>         synchronized (writeLock) {
>             synchronized(readLock) {
>                 if (!prompt.isEmpty()) {
>                     pw.print(prompt);
>                     pw.flush(); // automatic flushing does not cover print
>                 }
>                char[] array;
>                 try {
>                     array = readline(false);
>                 } catch (IOException x) {
>                     throw new IOError(x);
>                 }
>                 if (array != null) {
>                     return new String(array);
>                 }
>             }
>         }
>         return null;

This method started as a copy of `readLine`. In its current form, it's very evident how `readln` differs from `readLine`, and I would leave it this way for now. If the feature is standardised, we could refactor both methods together, as you suggested.

If the `java.io.IO` part of the feature or the feature itself is withdrawn, then we could consider refactoring the existing `readLine`. Does it make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592281687

From prappo at openjdk.org  Tue May  7 11:16:55 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 11:16:55 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
Message-ID: <PzNNXeGJOjdKQeyuR32Ofp4RnYNhQdRbW5h_FI3bnY8=.1bbabf4c-aaa7-43ad-938b-9c1537ee47f6@github.com>

On Tue, 7 May 2024 05:52:12 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 88:
> 
>> 86:         @Override
>> 87:         public JdkConsole println(Object obj) {
>> 88:             writer().println(obj);
> 
> the result of 'writer()' can be stored in a local variable (printing code are not JITed as often as the rest of the codes)

I assume it's about performance. If so, I would defer any performance-related tweaks until they are necessary. Interactive reading from console does not sound like something requiring that level of performance tweaking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592303463

From prappo at openjdk.org  Tue May  7 11:58:16 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 11:58:16 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
Message-ID: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>

Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

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

Commit messages:
 - Initial commit

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

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

From prappo at openjdk.org  Tue May  7 12:05:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 12:05:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <rwFuWs_IIJsPhKj5T4_C-CwJaeB4dCDHCAVBiLxS_ik=.3c274157-f47a-4a9f-94e8-fbdf03cd265e@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

This PR is standalone as opposed to dependent because the https://github.com/openjdk/jdk/pull/18787 dependency currently has a merge conflict, which complicates the required workflow.

This comment serves as a reminder to merge master into this PR once https://github.com/openjdk/jdk/pull/18787 has been integrated. If we don't do that, Skara will likely create a backport issue:

> (?? The fixVersion in this issue is [24] but the fixVersion in .jcheck/conf is 23, a new backport will be created when this pr is integrated.)

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

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2098246931

From forax at openjdk.org  Tue May  7 12:21:53 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 7 May 2024 12:21:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
 <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
Message-ID: <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>

On Tue, 7 May 2024 11:00:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 74:
>> 
>>> 72: 
>>> 73:     @Override
>>> 74:     public String readln(String prompt) {
>> 
>> this code can be simplified using an early return (and the body of the try/catch can be reduced so it is more clear which statement can cause the IOException)
>> 
>>         synchronized (writeLock) {
>>             synchronized(readLock) {
>>                 if (!prompt.isEmpty()) {
>>                     pw.print(prompt);
>>                     pw.flush(); // automatic flushing does not cover print
>>                 }
>>                char[] array;
>>                 try {
>>                     array = readline(false);
>>                 } catch (IOException x) {
>>                     throw new IOError(x);
>>                 }
>>                 if (array != null) {
>>                     return new String(array);
>>                 }
>>             }
>>         }
>>         return null;
>
> This method started as a copy of `readLine`. In its current form, it's very evident how `readln` differs from `readLine`, and I would leave it this way for now. If the feature is standardised, we could refactor both methods together, as you suggested.
> 
> If the `java.io.IO` part of the feature or the feature itself is withdrawn, then we could consider refactoring the existing `readLine`. Does it make sense?

I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience. 

You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be

>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 88:
>> 
>>> 86:         @Override
>>> 87:         public JdkConsole println(Object obj) {
>>> 88:             writer().println(obj);
>> 
>> the result of 'writer()' can be stored in a local variable (printing code are not JITed as often as the rest of the codes)
>
> I assume it's about performance. If so, I would defer any performance-related tweaks until they are necessary. Interactive reading from console does not sound like something requiring that level of performance tweaking.

yes, let see what @cl4es will say when he will test the time to print "hello world"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592385449
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592387034

From redestad at openjdk.org  Tue May  7 12:59:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 May 2024 12:59:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
 <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
 <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
Message-ID: <YQx4Hcn2TLeImHoj3PAYbVJIONzV4hIOkxisLrST3Cg=.b405394d-d207-44d8-8d11-a3204aa54256@github.com>

On Tue, 7 May 2024 12:18:52 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> I assume it's about performance. If so, I would defer any performance-related tweaks until they are necessary. Interactive reading from console does not sound like something requiring that level of performance tweaking.
>
> yes, let see what @cl4es will say when he will test the time to print "hello world"

@forax I don't think anything touched on here is used during bootstrap; perhaps there are apps we could cover that uses these APIs, but I think for line-based console IO a few calls in the interpreter is not going to make a noticeable difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592438417

From prappo at openjdk.org  Tue May  7 16:11:57 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 16:11:57 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
 <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
 <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
Message-ID: <7n1hCAP6_sXuoIWhRSSjV9qcAMbQGU7jOrbl9YE3Gk8=.4cc275ad-a3f5-486f-80f1-3a1fb5fede41@github.com>

On Tue, 7 May 2024 12:17:36 GMT, R?mi Forax <forax at openjdk.org> wrote:

> I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience.

We may call it differently, but I think both you and I are referring to this part of [JEP 12](https://openjdk.org/jeps/12) (emphasis mine):

> Eventually, the JEP owner must decide the preview feature's fate. If the decision is to remove the preview feature, then the owner must file an issue in JBS to remove the feature in the next JDK feature release; no new JEP is needed. **On the other hand, if the decision is to finalize, then the owner must file a new JEP, noting refinements informed by developer feedback. The title of this JEP should be the feature's name, omitting the earlier suffix of (Preview) / (Second Preview), and without adding any new suffix such as (Standard) or (Final). This JEP will ultimately reach Targeted status for the next JDK feature release.**

> You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be

Sorry, R?mi, but no. As long as this feature is in preview, I'd optimise for easier removal (back out) of the feature rather than clean combined code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592740269

From naoto at openjdk.org  Tue May  7 16:37:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 May 2024 16:37:55 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>

On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Looks good overall. Left some minor comments.

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

> 187:     /**
> 188:      * Writes a prompt as if by calling {@code print}, then reads a single line
> 189:      * of text from this system console.

Nit: I would not add `system` here as `this console` is consistent with other locations.

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

> 105:      * {@inheritDoc}
> 106:      *
> 107:      * @throws IOError {@inheritDoc}

Probably I am missing something, but I see `Console` declares this throws clause. Do we need this inheritDoc here?

test/jdk/java/io/IO/IO.java line 99:

> 97:                 System.getProperty("test.jdk") + "/bin/java",
> 98:                 "--enable-preview",
> 99:                 "-Djdk.console=gibberish",

The test comment suggests this test is testing the default console implementation, but the invocation specifies `-Djdk.console=gibberish` which defaults to java.base. Is this what you intended?

test/jdk/java/io/IO/Input.java line 33:

> 31:         System.out.print(readln("?"));
> 32:     }
> 33: }

Needs a newline

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

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2041904750
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1591704961
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592764263
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592773917
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592776068

From prappo at openjdk.org  Tue May  7 17:01:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:01:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
Message-ID: <HahWNODCYygUO446By-0_h5x_oQ_Oj4FjwP4l__votg=.2af250d7-e139-415f-bd3c-ea28a5dbb388@github.com>

On Tue, 7 May 2024 01:20:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> src/java.base/share/classes/java/io/Console.java line 189:
> 
>> 187:     /**
>> 188:      * Writes a prompt as if by calling {@code print}, then reads a single line
>> 189:      * of text from this system console.
> 
> Nit: I would not add `system` here as `this console` is consistent with other locations.

That is a typo; thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592805571

From prappo at openjdk.org  Tue May  7 17:17:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:17:53 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
Message-ID: <aIf4sgfHDBX_0iVghGYlcA4rGVwC1R0uOItaSI72Z1M=.004b8b95-8de7-40ee-a3e3-2b41c2d474f3@github.com>

On Tue, 7 May 2024 16:32:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> test/jdk/java/io/IO/IO.java line 99:
> 
>> 97:                 System.getProperty("test.jdk") + "/bin/java",
>> 98:                 "--enable-preview",
>> 99:                 "-Djdk.console=gibberish",
> 
> The test comment suggests this test is testing the default console implementation, but the invocation specifies `-Djdk.console=gibberish` which defaults to java.base. Is this what you intended?

That comment says that this test tests jdk.internal.io.JdkConsoleImpl, which belongs to java.base. But, if you read it the way you described, I should definitely rephrase it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592824491

From naoto at openjdk.org  Tue May  7 17:33:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 May 2024 17:33:55 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <aIf4sgfHDBX_0iVghGYlcA4rGVwC1R0uOItaSI72Z1M=.004b8b95-8de7-40ee-a3e3-2b41c2d474f3@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
 <aIf4sgfHDBX_0iVghGYlcA4rGVwC1R0uOItaSI72Z1M=.004b8b95-8de7-40ee-a3e3-2b41c2d474f3@github.com>
Message-ID: <6c1icHjQsD_oDj8OOoQCy0Vgw1h-HZJX0btKflAHTqQ=.b1dbda7c-89a4-4f3c-a7ae-14116729c8f0@github.com>

On Tue, 7 May 2024 17:15:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/jdk/java/io/IO/IO.java line 99:
>> 
>>> 97:                 System.getProperty("test.jdk") + "/bin/java",
>>> 98:                 "--enable-preview",
>>> 99:                 "-Djdk.console=gibberish",
>> 
>> The test comment suggests this test is testing the default console implementation, but the invocation specifies `-Djdk.console=gibberish` which defaults to java.base. Is this what you intended?
>
> That comment says that this test tests jdk.internal.io.JdkConsoleImpl, which belongs to java.base. But, if you read it the way you described, I should definitely rephrase it.

Sorry, I read it wrong. Your comment is clear so no need for rewording

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592840539

From prappo at openjdk.org  Tue May  7 17:40:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:40:52 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
Message-ID: <xHN8m8uZd3to9lSqUC_KKMrzRj5yVM_SAUq7lZrLVhk=.5bf13ec9-a638-4e59-8d88-0bd15a918619@github.com>

On Tue, 7 May 2024 16:24:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> src/java.base/share/classes/java/io/ProxyingConsole.java line 107:
> 
>> 105:      * {@inheritDoc}
>> 106:      *
>> 107:      * @throws IOError {@inheritDoc}
> 
> Probably I am missing something, but I see `Console` declares this throws clause. Do we need this inheritDoc here?

Yes, we do. There's a common misconception that `{@inheritDoc}` inherits the complete doc comment. In reality, `{@inheritDoc}` inherits only the main description, which does not include any `@throws` tags.

A `@throws` tag is either inherited explicitly, such as in L107, or implicitly. Implicit inheritance occurs when an exception is listed in the `throws` clause.

Since it's uncommon for unchecked exceptions (errors included) to be listed in the `throws` clause, unless inherited explicitly, their documentation will be missing from the overriding method documentation. Assuming, of course, that your intention is to have them there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592848314

From prappo at openjdk.org  Tue May  7 17:43:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:43:52 GMT
Subject: RFR: 8305457: Implement java.io.IO
In-Reply-To: <6c1icHjQsD_oDj8OOoQCy0Vgw1h-HZJX0btKflAHTqQ=.b1dbda7c-89a4-4f3c-a7ae-14116729c8f0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
 <aIf4sgfHDBX_0iVghGYlcA4rGVwC1R0uOItaSI72Z1M=.004b8b95-8de7-40ee-a3e3-2b41c2d474f3@github.com>
 <6c1icHjQsD_oDj8OOoQCy0Vgw1h-HZJX0btKflAHTqQ=.b1dbda7c-89a4-4f3c-a7ae-14116729c8f0@github.com>
Message-ID: <rdlVLy72Ge0jkoG6UYZ1n7mX6cqeakKD-PQ1DOAu_ps=.87f17715-aa23-488d-aa27-a9df3588740c@github.com>

On Tue, 7 May 2024 17:30:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Sorry, I read it wrong. Your comment is clear so no need for rewording

Still, I think that your misreading is a symptom of a problem with my wording. Let me try to rephrase it; let's see if you like it more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592852458

From prappo at openjdk.org  Tue May  7 17:47:20 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 17:47:20 GMT
Subject: RFR: 8305457: Implement java.io.IO [v2]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <Dctq5oaa_NKxZ-qs70wv_DLa6qKMOE_yMaUzjU-nI_4=.07cf47b4-461a-477a-ba86-cd8f215ce1ce@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

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

  Respond to feedback from @naotoj
  
    - typo
    - trailing newlines
    - better wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/ef888fd8..60050834

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

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

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

From prappo at openjdk.org  Tue May  7 19:46:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 19:46:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

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

  Strengthen tests after 8330998
  
  https://github.com/openjdk/jdk/pull/18996 now allows us to test
  Console IO better.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/60050834..73a20a7c

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

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

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

From darcy at openjdk.org  Tue May  7 19:53:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 May 2024 19:53:53 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <xHN8m8uZd3to9lSqUC_KKMrzRj5yVM_SAUq7lZrLVhk=.5bf13ec9-a638-4e59-8d88-0bd15a918619@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <oPnpS6oaWew4cUZCzwMCOG9AvMvSMLuIkRhcJAjEefU=.46da5ff7-f99f-498d-aa3f-99147dae0195@github.com>
 <xHN8m8uZd3to9lSqUC_KKMrzRj5yVM_SAUq7lZrLVhk=.5bf13ec9-a638-4e59-8d88-0bd15a918619@github.com>
Message-ID: <z1iWLVaePCJLF6p8A9FeZ6TYJglUgvMPC4XTzzuQ38k=.5ddf6e86-ad0a-4120-b7c2-88bb82c17f75@github.com>

On Tue, 7 May 2024 17:37:57 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Yes, we do. There's a common misconception that `{@inheritDoc}` inherits the complete doc comment. In reality, `{@inheritDoc}` inherits only the main description, which does not include any `@throws` tags.
> 
> A `@throws` tag is either inherited explicitly, such as in L107, or implicitly. Implicit inheritance occurs when an exception is listed in the `throws` clause.
> 
> Since it's uncommon for unchecked exceptions (errors included) to be listed in the `throws` clause, unless inherited explicitly, their documentation will be missing from the overriding method documentation. Assuming, of course, that your intention is to have them there.

While it may be surprising that `{@inheritDoc}` doesn't inherit the complete doc, it is a feature rather than a bug since an overridden method is allowed to throw fewer exceptions than the method it overrides.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592985138

From darcy at openjdk.org  Tue May  7 20:07:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 May 2024 20:07:51 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <kmTopgOeZ_Yf6eiPc0Gh7oM0LZ6oHcVqOSN8SCzNCjI=.5eab6555-7e8b-4a52-a640-6cc161284a60@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Marked as reviewed by darcy (Reviewer).

> This PR is standalone as opposed to dependent because the #18787 dependency currently has a merge conflict, which complicates the required workflow.
> 
> This comment serves as a reminder to merge master into this PR once #18787 has been integrated. If we don't do that, Skara will likely create a backport issue:
> 
> > (?? The fixVersion in this issue is [24] but the fixVersion in .jcheck/conf is 23, a new backport will be created when this pr is integrated.)

Thanks @pavelrappo. For as a small risk-reduction exercise, the fixVersion on the bug could also be changed to tbd, but if it is integrated after the main start-of-release PR it should be fine.

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

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2044060259
PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2099210018

From forax at openjdk.org  Tue May  7 20:14:52 2024
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 7 May 2024 20:14:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <7n1hCAP6_sXuoIWhRSSjV9qcAMbQGU7jOrbl9YE3Gk8=.4cc275ad-a3f5-486f-80f1-3a1fb5fede41@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <hVlQ7frdWV-o3-F0NHmZu1dnQqu2ZZqC03IFbR-I-yE=.c611d97e-31a9-4d22-9f53-b1bdd71467c5@github.com>
 <yQGqIb5RQtadQA_bu-8JdUJDUdi_UEySF8Sm1-Bb5-c=.03331a10-d436-4ae7-8c88-e8d7649e8ec5@github.com>
 <OOeWi7f89VKud_6Sp7Z9AMdzPXexJl6sb6N6k-T2xFs=.5c5af026-02da-4d9d-987c-d62eaaf54ff6@github.com>
 <7n1hCAP6_sXuoIWhRSSjV9qcAMbQGU7jOrbl9YE3Gk8=.4cc275ad-a3f5-486f-80f1-3a1fb5fede41@github.com>
Message-ID: <kcmVvhW3-bOuiA1oXOXbRrVqvJphybsFZx_4HNOCWrc=.c2989151-0dd9-4299-aa27-99e758d13002@github.com>

On Tue, 7 May 2024 16:09:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience. 
>> 
>> You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be
>
>> I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience.
> 
> We may call it differently, but I think both you and I are referring to this part of [JEP 12](https://openjdk.org/jeps/12) (emphasis mine):
> 
>> Eventually, the JEP owner must decide the preview feature's fate. If the decision is to remove the preview feature, then the owner must file an issue in JBS to remove the feature in the next JDK feature release; no new JEP is needed. **On the other hand, if the decision is to finalize, then the owner must file a new JEP, noting refinements informed by developer feedback. The title of this JEP should be the feature's name, omitting the earlier suffix of (Preview) / (Second Preview), and without adding any new suffix such as (Standard) or (Final). This JEP will ultimately reach Targeted status for the next JDK feature release.**
> 
>> You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be
> 
> Sorry, R?mi, but no. As long as this feature is in preview, I'd optimise for easier removal (back out) of the feature rather than clean combined code.

Okay

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593013670

From prappo at openjdk.org  Tue May  7 20:26:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 20:26:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
 <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>
Message-ID: <mmUl8dkLjrfAs1utQ0e5zn8Knz2ZV3UzM8x4KxB4wtc=.c95890ba-267d-4c0f-8351-4d78cee2f024@github.com>

On Tue, 7 May 2024 02:54:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/IO.java line 41:
>> 
>>> 39:  */
>>> 40: @PreviewFeature(feature = PreviewFeature.Feature.IMPLICIT_CLASSES)
>>> 41: public class IO {
>> 
>> Should this be final?
>
>> Should this be final?
> 
> With only the private constructor, it doesn't matter too much in practice, but an explicit `final` would be good documentation if that is the intent.

If the sole constructor of a class is private, not only does it preclude the class from being instantiated, but it also precludes the class from being extended. Mind you, even with the sole private constructor, both instantiation and extension are still possible from inside the class or its nested classes. As long as we don't leak such instances to API clients, they won't seem to be able to observe any difference between "the private constructor" and "the private constructor of a final class".

I think that just having that constructor private but the class "non-final" makes bigger bang for the buck. We can defer the decision to make the class final.

If this helps, here are a few well-known similar classes:

  - java.util.Collections
  - java.util.concurrent.Executors

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593033564

From smarks at openjdk.org  Tue May  7 21:24:53 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 7 May 2024 21:24:53 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <gKKAsZP1N9udDAXkoQC8yhVy8AFSp_tJxz5IwHLIkCc=.3cd32f19-2e4e-424f-9018-97f2015b9ae8@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

src/java.base/share/classes/java/io/IO.java line 37:

> 35:  * is {@code null}; otherwise, the effect is as if a similarly-named method
> 36:  * had been called on that console.
> 37:  *

Add a note here on encoding (character set), something like


Output from methods in this class uses the character set of the system console as specified by {@link Console#charset}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593109243

From prappo at openjdk.org  Tue May  7 22:10:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 22:10:53 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <Ax3HA7Cn9cS7l4Sq6zx7hKROScWxfaxstyVbYYjwsjk=.2dbd81da-e52b-4fa6-96ad-806e6f8da96e@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Thanks for reviewing it Joe, I'm now delegating integration of this PR to @JesperIRL, you, or anyone who will be integrating https://github.com/openjdk/jdk/pull/18787.

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

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2099395990

From prappo at openjdk.org  Tue May  7 22:16:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 May 2024 22:16:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <gKKAsZP1N9udDAXkoQC8yhVy8AFSp_tJxz5IwHLIkCc=.3cd32f19-2e4e-424f-9018-97f2015b9ae8@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <gKKAsZP1N9udDAXkoQC8yhVy8AFSp_tJxz5IwHLIkCc=.3cd32f19-2e4e-424f-9018-97f2015b9ae8@github.com>
Message-ID: <-rUItvjHKXhD8yc7EaIbPOHHdu15dbYID0QU2uNutlU=.877dcab0-a5c7-493b-b62b-e0adb0a2ce40@github.com>

On Tue, 7 May 2024 21:19:59 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/IO.java line 37:
> 
>> 35:  * is {@code null}; otherwise, the effect is as if a similarly-named method
>> 36:  * had been called on that console.
>> 37:  *
> 
> Add a note here on encoding (character set), something like
> 
> 
> Output from methods in this class uses the character set of the system console as specified by {@link Console#charset}.

Seems redundant since we express `IO` methods in therms of those of `Console` in the specification, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593161920

From jjg at openjdk.org  Tue May  7 22:49:52 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 May 2024 22:49:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <I2vdyKRyeXvT4eh5stuey2iikuERgf0FaTWcLH0zfkU=.e5752386-61d8-4479-a554-1be2192baa8b@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2044314419

From smarks at openjdk.org  Wed May  8 01:10:55 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 May 2024 01:10:55 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <-rUItvjHKXhD8yc7EaIbPOHHdu15dbYID0QU2uNutlU=.877dcab0-a5c7-493b-b62b-e0adb0a2ce40@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <gKKAsZP1N9udDAXkoQC8yhVy8AFSp_tJxz5IwHLIkCc=.3cd32f19-2e4e-424f-9018-97f2015b9ae8@github.com>
 <-rUItvjHKXhD8yc7EaIbPOHHdu15dbYID0QU2uNutlU=.877dcab0-a5c7-493b-b62b-e0adb0a2ce40@github.com>
Message-ID: <FKuFd0k7gxnh7AIL-FyolcXlffAhCA6ER8M_6HMAXDQ=.a889a65b-6572-4f37-b735-39a590caa659@github.com>

On Tue, 7 May 2024 22:12:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/IO.java line 37:
>> 
>>> 35:  * is {@code null}; otherwise, the effect is as if a similarly-named method
>>> 36:  * had been called on that console.
>>> 37:  *
>> 
>> Add a note here on encoding (character set), something like
>> 
>> 
>> Output from methods in this class uses the character set of the system console as specified by {@link Console#charset}.
>
> Seems redundant since we express `IO` methods in therms of those of `Console` in the specification, no?

It's strictly redundant in the sense that, if one reads all the specifications and applies reasoning using the right facts, one could already reach that conclusion. However, I think it's a useful clarification, because if you're looking at `java.io.IO` and you ask what charset it uses, you might not know that you need to look at the `Console.charset` method. You might go looking on Console to find the answer, and you might or might not find that method. (Arguably Console's specs should be improved too since the charset is a global property of the Console instance and this should be mentioned in the class specs.)

Anyway Joe asked about Locales in the comments on the CSR [JDK-8331610](https://bugs.openjdk.org/browse/JDK-8331610) and while Locale isn't relevant, charset is, so it seems reasonable to mention it explicitly here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593257656

From jpai at openjdk.org  Wed May  8 05:44:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:44:54 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

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

> 186: 
> 187:     /**
> 188:      * Writes a prompt as if by calling {@code print}, then reads a single line

Should `{@code print}` instead be `{@link Console#print() print()}`?

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

> 190:      *
> 191:      * @param  prompt
> 192:      *         A prompt string.

Hello Pavel, should this specify whether `prompt`  can be null?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593411945
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593411393

From jpai at openjdk.org  Wed May  8 05:50:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:50:59 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <1dohhjiIFuH5FXBkA0YnD4rSmR-e0Bs5A1_zQTkVxDY=.c5fc9a18-83ca-4bb5-abfe-1ca3e8e4a024@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

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

> 192:      *         A prompt string.
> 193:      *
> 194:      * @throws IOError

I'm guessing this specifies `IOError` instead of `IOException` so that the caller doesn't have to handle a checked exception? If so, would it be better to throw an `java.io.UncheckedIOException`, to avoid throwing `Error`s?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593414616

From jpai at openjdk.org  Wed May  8 05:51:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:51:00 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <1dohhjiIFuH5FXBkA0YnD4rSmR-e0Bs5A1_zQTkVxDY=.c5fc9a18-83ca-4bb5-abfe-1ca3e8e4a024@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <1dohhjiIFuH5FXBkA0YnD4rSmR-e0Bs5A1_zQTkVxDY=.c5fc9a18-83ca-4bb5-abfe-1ca3e8e4a024@github.com>
Message-ID: <Wnx97Qh19TRpMUBxvInc_7b_gksS6-t_tKRAt0awG_o=.9c362e3d-cb68-4839-a1c2-310eebd28000@github.com>

On Wed, 8 May 2024 05:45:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/Console.java line 194:
> 
>> 192:      *         A prompt string.
>> 193:      *
>> 194:      * @throws IOError
> 
> I'm guessing this specifies `IOError` instead of `IOException` so that the caller doesn't have to handle a checked exception? If so, would it be better to throw an `java.io.UncheckedIOException`, to avoid throwing `Error`s?

Actually, it appears that the existing APIs on `java.io.Console` are specified to throw a `java.io.IOError`. So this isn't something new that is being introduced. So please ignore that question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593416464

From jpai at openjdk.org  Wed May  8 05:55:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 05:55:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <Z-0pp39dfPkKEtHlkyKtwKBlTI5dW8lnVl-MtJfuYNw=.034ab167-99ed-4fde-84cf-daca6998726f@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

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

> 149:     /**
> 150:      * Writes a string representation of the specified object to this console's
> 151:      * output stream, terminates the line and then flushes the console.

Should this specify if the line termination will be platform dependent character(s) or independent of the platform?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593420018

From jpai at openjdk.org  Wed May  8 06:01:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 06:01:56 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
Message-ID: <gDowRhUuCc_bTGTQbQXb7Q7CffLt2d-FDQ9S12ZhUtI=.2ae7ac74-4b78-4c4a-9a62-bb0f84ea0dd6@github.com>

On Tue, 7 May 2024 19:46:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Strengthen tests after 8330998
>   
>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>   Console IO better.

src/java.base/share/classes/java/io/IO.java line 51:

> 49:      * console, terminates the line and then flushes that console.
> 50:      *
> 51:      * If {@code System.console()} returns {@code null}, throws {@code IOError}.

Unlike, `java.io.Console` whose existing methods already throw `IOError`, should these new methods on `java.io.IO` instead throw `java.io.UncheckedIOException` instead of throwing `Error`s?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593424569

From prappo at openjdk.org  Wed May  8 09:03:54 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 09:03:54 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
Message-ID: <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>

On Wed, 8 May 2024 05:41:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/Console.java line 188:
> 
>> 186: 
>> 187:     /**
>> 188:      * Writes a prompt as if by calling {@code print}, then reads a single line
> 
> Should `{@code print}` instead be `{@link Console#print() print()}`?

It could be done like that, but given that it's the same class (and the same HTML page), I'd skip it.

> src/java.base/share/classes/java/io/Console.java line 192:
> 
>> 190:      *
>> 191:      * @param  prompt
>> 192:      *         A prompt string.
> 
> Hello Pavel, should this specify whether `prompt`  can be null?

If we specify that, it would be very much unlike all other `Console` methods that are covered by this:

    * Unless otherwise specified, passing a {@code null} argument to any method
    * in this class will cause a {@link NullPointerException} to be thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593687355
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593684673

From prappo at openjdk.org  Wed May  8 09:18:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 09:18:56 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <gDowRhUuCc_bTGTQbQXb7Q7CffLt2d-FDQ9S12ZhUtI=.2ae7ac74-4b78-4c4a-9a62-bb0f84ea0dd6@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <gDowRhUuCc_bTGTQbQXb7Q7CffLt2d-FDQ9S12ZhUtI=.2ae7ac74-4b78-4c4a-9a62-bb0f84ea0dd6@github.com>
Message-ID: <8W3Rbf8KHYoe3Ny1UkmvLAiucRV6_SXMTa0aaxNwP9Y=.3e7982cb-bd18-4b7c-9ac2-21d3eec746c5@github.com>

On Wed, 8 May 2024 05:59:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/IO.java line 51:
> 
>> 49:      * console, terminates the line and then flushes that console.
>> 50:      *
>> 51:      * If {@code System.console()} returns {@code null}, throws {@code IOError}.
> 
> Unlike, `java.io.Console` whose existing methods already throw `IOError`, should these new methods on `java.io.IO` instead throw `java.io.UncheckedIOException` instead of throwing `Error`s?

As a result of several offline discussions, it was decided to throw `IOError` to better align with `java.io.Console`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593711476

From prappo at openjdk.org  Wed May  8 09:41:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 09:41:58 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <Z-0pp39dfPkKEtHlkyKtwKBlTI5dW8lnVl-MtJfuYNw=.034ab167-99ed-4fde-84cf-daca6998726f@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <Z-0pp39dfPkKEtHlkyKtwKBlTI5dW8lnVl-MtJfuYNw=.034ab167-99ed-4fde-84cf-daca6998726f@github.com>
Message-ID: <3CquRSEBEyllynsP_PQ4oAPLYR_6itliFG5urQxgcNA=.a92842dc-9e1e-404c-9c65-894571609320@github.com>

On Wed, 8 May 2024 05:53:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Strengthen tests after 8330998
>>   
>>   https://github.com/openjdk/jdk/pull/18996 now allows us to test
>>   Console IO better.
>
> src/java.base/share/classes/java/io/Console.java line 151:
> 
>> 149:     /**
>> 150:      * Writes a string representation of the specified object to this console's
>> 151:      * output stream, terminates the line and then flushes the console.
> 
> Should this specify if the line termination will be platform dependent character(s) or independent of the platform?

That's a good question. I think it should. That `println` method is not specified in terms of `printf` or `format`. Thus, we cannot reduce `println` to, say, `printf("%s%n", obj)`, leaning on `Formatter`'s definition of `%n`:

    'n'	line separator	The result is the platform-specific line separator

@stuart-marks, any thoughts on wording? Mind you, if we add any such wording, we'll have to update CSR too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593742851

From jpai at openjdk.org  Wed May  8 10:34:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 8 May 2024 10:34:53 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
Message-ID: <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>

On Wed, 8 May 2024 08:59:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 192:
>> 
>>> 190:      *
>>> 191:      * @param  prompt
>>> 192:      *         A prompt string.
>> 
>> Hello Pavel, should this specify whether `prompt`  can be null?
>
> If we specify that, it would be very much unlike all other `Console` methods that are covered by this:
> 
>     * Unless otherwise specified, passing a {@code null} argument to any method
>     * in this class will cause a {@link NullPointerException} to be thrown.

I haven't given it a try, but a brief look at the code suggests that if the console implementation backed by JLine gets used, then a `null` prompt may not generate a `NullPointerException` (since JLine appears to allow `null`) whereas if the internal JDK console implementation gets used then a `NullPointerException` will get thrown. If the expectation is to disallow a `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand off to the underlying console implementations might be required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1593809280

From prappo at openjdk.org  Wed May  8 13:15:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 13:15:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
Message-ID: <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>

On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> If we specify that, it would be very much unlike all other `Console` methods that are covered by this:
>> 
>>     * Unless otherwise specified, passing a {@code null} argument to any method
>>     * in this class will cause a {@link NullPointerException} to be thrown.
>
> I haven't given it a try, but a brief look at the code suggests that if the console implementation backed by JLine gets used, then a `null` prompt may not generate a `NullPointerException` (since JLine appears to allow `null`) whereas if the internal JDK console implementation gets used then a `NullPointerException` will get thrown. If the expectation is to disallow a `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand off to the underlying console implementations might be required.

Good catch! `jdk.internal.org.jline.JdkConsoleProviderImpl.JdkConsoleImpl.readln(null)` does not throw `NullPointerException` (NPE), which it must. I'll fix the bug and add a test.

Speaking of NPE. The newly added `Console.print` and `Console.println` methods do not throw NPE if passed null. While that's how it should be, they don't specify that, so the class-level NPE clause applies:

    * Unless otherwise specified, passing a {@code null} argument to any method
    * in this class will cause a {@link NullPointerException} to be thrown.
    ...
    public sealed class Console implements Flushable permits ProxyingConsole {

I'll fix that.

We should also specify NPE (or absence thereof) on methods of `IO`. Otherwise, this package clause applies:

    * Unless otherwise noted, passing a {@code null} argument to a constructor or
    * method in any class or interface in this package will cause a
    * {@code NullPointerException} to be thrown.
    ...
    package java.io;

@stuart-marks speaking of exceptions. Do we need to add explicit `@throws` tag to `IO` methods?

    @throws {@code IOError} if {@code System.console()} returns {@code null}

While it would make sense, it would also look superfluous: we already specify that error condition in the class comment and then in every method's main description. Do we need to add one more note on `IOError`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594013064

From smarks at openjdk.org  Wed May  8 16:08:53 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 May 2024 16:08:53 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <3CquRSEBEyllynsP_PQ4oAPLYR_6itliFG5urQxgcNA=.a92842dc-9e1e-404c-9c65-894571609320@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <Z-0pp39dfPkKEtHlkyKtwKBlTI5dW8lnVl-MtJfuYNw=.034ab167-99ed-4fde-84cf-daca6998726f@github.com>
 <3CquRSEBEyllynsP_PQ4oAPLYR_6itliFG5urQxgcNA=.a92842dc-9e1e-404c-9c65-894571609320@github.com>
Message-ID: <hXdEZvBFHYhtw7vneAjpT-dM5FbF7fJEQdW1n_L0608=.6e2bc424-c734-4867-bf68-f442b5896bbf@github.com>

On Wed, 8 May 2024 09:39:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 151:
>> 
>>> 149:     /**
>>> 150:      * Writes a string representation of the specified object to this console's
>>> 151:      * output stream, terminates the line and then flushes the console.
>> 
>> Should this specify if the line termination will be platform dependent character(s) or independent of the platform?
>
> That's a good question. I think it should. That `println` method is not specified in terms of `printf` or `format`. Thus, we cannot reduce `println` to, say, `printf("%s%n", obj)`, leaning on `Formatter`'s definition of `%n`:
> 
>     'n'	line separator	The result is the platform-specific line separator
> 
> @stuart-marks, any thoughts on wording? Mind you, if we add any such wording, we'll have to update CSR too.

Well `Formatter` defers to `System.lineSeparator()` so I think we should refer to that. Not sure that needs to be repeated in `java.io.IO`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594281188

From smarks at openjdk.org  Wed May  8 16:08:54 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 May 2024 16:08:54 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
Message-ID: <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>

On Wed, 8 May 2024 13:13:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I haven't given it a try, but a brief look at the code suggests that if the console implementation backed by JLine gets used, then a `null` prompt may not generate a `NullPointerException` (since JLine appears to allow `null`) whereas if the internal JDK console implementation gets used then a `NullPointerException` will get thrown. If the expectation is to disallow a `null` prompt, then perhaps `Objects.requireNonNull(prompt)` before we hand off to the underlying console implementations might be required.
>
> Good catch! `jdk.internal.org.jline.JdkConsoleProviderImpl.JdkConsoleImpl.readln(null)` does not throw `NullPointerException` (NPE), which it must. I'll fix the bug and add a test.
> 
> Speaking of NPE. The newly added `Console.print` and `Console.println` methods do not throw NPE if passed null. While that's how it should be, they don't specify that, so the class-level NPE clause applies:
> 
>     * Unless otherwise specified, passing a {@code null} argument to any method
>     * in this class will cause a {@link NullPointerException} to be thrown.
>     ...
>     public sealed class Console implements Flushable permits ProxyingConsole {
> 
> I'll fix that.
> 
> We should also specify NPE (or absence thereof) on methods of `IO`. Otherwise, this package clause applies:
> 
>     * Unless otherwise noted, passing a {@code null} argument to a constructor or
>     * method in any class or interface in this package will cause a
>     * {@code NullPointerException} to be thrown.
>     ...
>     package java.io;
> 
> @stuart-marks speaking of exceptions. Do we need to add explicit `@throws` tag to `IO` methods?
> 
>     @throws {@code IOError} if {@code System.console()} returns {@code null}
> 
> While it would make sense, it would also look superfluous: we already specify that error condition in the class comment and then in every method's main description. Do we need to add one more note on `IOError`?

Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594282580

From naoto at openjdk.org  Wed May  8 17:07:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 May 2024 17:07:07 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v4]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <iQtfvg5kPN-UslgHMTJijnGHM09Be4DYgTyecp-KRqA=.bedab44c-7528-4b21-9c59-cd355cba10c1@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

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

  Removed JdkConsole.printf()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/29ff6063..2e83fc7b

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

  Stats: 20 lines in 5 files changed: 0 ins; 19 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

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

From prappo at openjdk.org  Wed May  8 18:28:52 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 18:28:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
 <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>
Message-ID: <IY4TieJPjmWSdKQaPXzSa-Ud4kjq1_fjjQBncwTsiGg=.fc991711-78da-45b6-bd4b-0bc8d8284eb7@github.com>

On Wed, 8 May 2024 16:06:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.

Right, in our current model, `Console.readln(prompt)` can be reduced to `Console.print(prompt)` followed by actual reading. `Console.print(prompt)` can in turn be reduced to printing the result of `String.valueOf((Object) prompt)`, which is a string "null".

The above reduction means that `Console.readln(null)` will not throw NPE. Now, what I'm asking if that's what we really want.

With `Console.println(null)` and `Console.print(null)` not throwing NPE makes sense. However, with `Console.readln(null)` it might not. After all, we ask for a **`String`** prompt, not an `Object` prompt. All other methods of `Console` that accept `String`, throw NPE if that string is null.

One more consideration. Whatever the behaviour we choose for `Console.readln(null)`, we should choose the same behaviour for `IO.readln(null)`. Otherwise, it would be a constant source of unpleasantly surprising inconsistency.

Thoughts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594464589

From prappo at openjdk.org  Wed May  8 18:43:41 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 18:43:41 GMT
Subject: RFR: 8305457: Implement java.io.IO [v4]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <wqdl7WD8hTx1IlgxXylCd053e_MrKw0zrHKC2fwUusM=.b5072cb6-85b7-46c8-9ebd-119a63ec029b@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Specify charset of java.io.IO
 - Use system-dependent line separator for Console.println

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/73a20a7c..80eacf8c

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

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

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

From smarks at openjdk.org  Wed May  8 19:42:52 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 8 May 2024 19:42:52 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <IY4TieJPjmWSdKQaPXzSa-Ud4kjq1_fjjQBncwTsiGg=.fc991711-78da-45b6-bd4b-0bc8d8284eb7@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
 <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>
 <IY4TieJPjmWSdKQaPXzSa-Ud4kjq1_fjjQBncwTsiGg=.fc991711-78da-45b6-bd4b-0bc8d8284eb7@github.com>
Message-ID: <bX9rOfeN_f5pV3Yv_uCCSDYoWnjzsdWhvas5MyUqx-A=.3e0697c9-278d-45ea-896e-6e4c89d8d839@github.com>

On Wed, 8 May 2024 18:25:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.
>
>> Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.
> 
> Right, in our current model, `Console.readln(prompt)` can be reduced to `Console.print(prompt)` followed by actual reading. `Console.print(prompt)` can in turn be reduced to printing the result of `String.valueOf((Object) prompt)`, which is a string "null".
> 
> The above reduction means that `Console.readln(null)` will not throw NPE. Now, what I'm asking if that's what we really want.
> 
> With `Console.println(null)` and `Console.print(null)` not throwing NPE makes sense. However, with `Console.readln(null)` it might not. After all, we ask for a **`String`** prompt, not an `Object` prompt. All other methods of `Console` that accept `String`, throw NPE if that string is null.
> 
> One more consideration. Whatever the behaviour we choose for `Console.readln(null)`, we should choose the same behaviour for `IO.readln(null)`. Otherwise, it would be a constant source of unpleasantly surprising inconsistency.
> 
> Thoughts?

A fair question, whether to treat `readln` differently because it takes a String argument instead of an Object.

I guess I'd like to see a scheme like the following:

    String s = cons.readln(prompt);

is effectively the same as

    cons.print(prompt);
    cons.flush();
    String s = cons.readLine(); // note no-arg readLine() method

In other words, define `readln` to behave "as if" the other methods were called. This would end up with a null prompt argument printing "null" and not throwing NPE.

This is internally consistent, at least. Beginning programmers will eventually learn that using null will lead to NPE. It might make things easier if NPEs were kept out of this little corner of the library. That's just my guess though.

Also, recall that `String.valueOf((Object) null)` and `String.valueOf((String) null)` both result in "null". But if one were to write `String.valueOf(null)` that throws NPE, because that selects the `valueOf(char[])` overload. That's kind of the outlier. Note further that the built-in `+` string concatenation operator will also convert null references to "null".

Personally I've always hated that string conversions of null in Java often result in "null" but it's baked into the system fairly deeply, so I think we should stick with it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594542505

From prappo at openjdk.org  Wed May  8 22:55:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 May 2024 22:55:56 GMT
Subject: RFR: 8305457: Implement java.io.IO [v3]
In-Reply-To: <bX9rOfeN_f5pV3Yv_uCCSDYoWnjzsdWhvas5MyUqx-A=.3e0697c9-278d-45ea-896e-6e4c89d8d839@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wpwFGOp8E00csxi2Xb9b-02ZlkqnIZEpo8AqaMsQ4AM=.90acb47b-effc-4838-ba80-28938d4dc3c0@github.com>
 <C1Pvc8KO7vUGELLaqcXpepoK_MpvChaDcZqfroVICo0=.5ab8bef5-fa21-4618-a903-219d733045a0@github.com>
 <jWOXcC9B_23P_Px2zulnzRc38zL7zkslJM9nRtauHlk=.55e2ed38-59b7-4df1-be13-5d9a74672e26@github.com>
 <yZdbfOOkmceBWA5_ybn4g9cLTI-a40mvJ9eT6c_5YI4=.b5715149-8051-43bc-8556-1bc217bdfc39@github.com>
 <QOraUtvx4uq8mQagpLv6RQDsY-bD5YcvspNegJ9R9O4=.8b4a7dec-6445-4dc0-bbe3-a74385e00826@github.com>
 <kXr9EdR3dWGNLqQRenj1LcwWTChuqmc6gA7r04R9nAo=.76e57556-5210-45ae-8e13-755a604c0c49@github.com>
 <IY4TieJPjmWSdKQaPXzSa-Ud4kjq1_fjjQBncwTsiGg=.fc991711-78da-45b6-bd4b-0bc8d8284eb7@github.com>
 <bX9rOfeN_f5pV3Yv_uCCSDYoWnjzsdWhvas5MyUqx-A=.3e0697c9-278d-45ea-896e-6e4c89d8d839@github.com>
Message-ID: <vg1basj8I5R8IC4I_jenDq3Ebuv1dmutpSRMZxt_9Y8=.42eef136-d696-45fd-8393-39ac30ce3c6d@github.com>

On Wed, 8 May 2024 19:40:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> Most of these are defined in terms of `String.valueOf(Object)` which if passed a null reference will return the String object containing `null`. So no, I don't think NPE should be thrown. It might be worth mentioning this explicitly somewhere though.
>> 
>> Right, in our current model, `Console.readln(prompt)` can be reduced to `Console.print(prompt)` followed by actual reading. `Console.print(prompt)` can in turn be reduced to printing the result of `String.valueOf((Object) prompt)`, which is a string "null".
>> 
>> The above reduction means that `Console.readln(null)` will not throw NPE. Now, what I'm asking if that's what we really want.
>> 
>> With `Console.println(null)` and `Console.print(null)` not throwing NPE makes sense. However, with `Console.readln(null)` it might not. After all, we ask for a **`String`** prompt, not an `Object` prompt. All other methods of `Console` that accept `String`, throw NPE if that string is null.
>> 
>> One more consideration. Whatever the behaviour we choose for `Console.readln(null)`, we should choose the same behaviour for `IO.readln(null)`. Otherwise, it would be a constant source of unpleasantly surprising inconsistency.
>> 
>> Thoughts?
>
> A fair question, whether to treat `readln` differently because it takes a String argument instead of an Object.
> 
> I guess I'd like to see a scheme like the following:
> 
>     String s = cons.readln(prompt);
> 
> is effectively the same as
> 
>     cons.print(prompt);
>     cons.flush();
>     String s = cons.readLine(); // note no-arg readLine() method
> 
> In other words, define `readln` to behave "as if" the other methods were called. This would end up with a null prompt argument printing "null" and not throwing NPE.
> 
> This is internally consistent, at least. Beginning programmers will eventually learn that using null will lead to NPE. It might make things easier if NPEs were kept out of this little corner of the library. That's just my guess though.
> 
> Also, recall that `String.valueOf((Object) null)` and `String.valueOf((String) null)` both result in "null". But if one were to write `String.valueOf(null)` that throws NPE, because that selects the `valueOf(char[])` overload. That's kind of the outlier. Note further that the built-in `+` string concatenation operator will also convert null references to "null".
> 
> Personally I've always hated that string conversions of null in Java often result in "null" but it's baked into the system fairly deeply, so I think we should stick with it.

Okay, I'll push a commit soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1594784225

From dholmes at openjdk.org  Thu May  9 08:21:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 May 2024 08:21:52 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

I think we may have to restore this to a standalone start-of-release change done after the other start-of-release changes. I had forgotten about the need to update the flags sections of java.1

src/java.base/share/man/java.1 line 3856:

> 3854: .SH REMOVED JAVA OPTIONS
> 3855: .PP
> 3856: These \f[V]java\f[R] options have been removed in JDK 24 and using them

This is incorrect. You can't just change 23 to 24 here as the actual set of flags listed below will be will be different.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19119#pullrequestreview-2047411800
PR Review Comment: https://git.openjdk.org/jdk/pull/19119#discussion_r1595128505

From prappo at openjdk.org  Thu May  9 11:15:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 11:15:53 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v4]
In-Reply-To: <odGBY-01VvMY90f3GM90D6SDIFkm4DQPE0C1_5SAJGk=.e2fba76c-9946-4abc-8c83-cd34d6045735@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <odGBY-01VvMY90f3GM90D6SDIFkm4DQPE0C1_5SAJGk=.e2fba76c-9946-4abc-8c83-cd34d6045735@github.com>
Message-ID: <8wmaKKFSe9sRJviyzVlP_dK5N7NjM5wThurAXHSDLFk=.7dd6b418-e82c-4ed1-ab95-8737b99f997a@github.com>

On Tue, 7 May 2024 07:13:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding another test run with -Djdk.console=java.base, as suggested.

Jan, if you integrate it soon, I'll improve testing in https://github.com/openjdk/jdk/pull/19112. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19081#issuecomment-2102463081

From jlahoda at openjdk.org  Thu May  9 13:57:03 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 9 May 2024 13:57:03 GMT
Subject: Integrated: 8327476: Upgrade JLine to 3.26.1
In-Reply-To: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
References: <pHNtAVen8OlH1grEnObJq0VWBrzoqI1zlAHZL84MdBk=.b5cb77e1-4345-4919-9bbb-4a292a76534e@github.com>
Message-ID: <TG_0bdoE48GRW9ItpOYN-Z3zZxa71vwc2GyMf5h4-uQ=.1023195e-cc04-4e87-bf13-950a1701c407@github.com>

On Wed, 6 Mar 2024 21:20:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a patch that:
> a) upgrades the JLine inside the JDK to 3.25.1
> b) since the new version of JLine has a FFM backend, our custom native backends are removed, and replaced with the FFM backend
> 
> Some changes had to be made to the original JLine in order to fit into the JDK. Most of them were already done for the previous version (repackaging, avoiding non-ASCII characters, commenting out logging, adding ability to modify to wrap the InputStream used by the terminal), and have only been transferred to the new one. The main two new changes are:
> - fixes to the FFM backend, so that it works on Linux and JDK 22. These have been proposed to JLine itself: https://github.com/jline/jline3/pull/945
> - disabling the `NativeFileDescriptorCreator`, as I believe we don't need it, and cannot make it work easily
> 
> There's a full patch between the `src/jdk.internal.le/share/classes/jdk/internal/org` and the merged content of the corresponding sources of these original JLine sub-projects:
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/reader
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal-ffm
> https://github.com/jline/jline3/tree/jline-parent-3.25.1/terminal
> the patch is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade.diff
> 
> I've also cleaned the patch a little removing most of the changes for the rename. The result is here:
> https://cr.openjdk.org/~jlahoda/8327476/jline-3.25.1-upgrade-significant.diff

This pull request has now been integrated.

Changeset: aaa90b30
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aaa90b3005c85852971203ce6feb88e7091e167b
Stats:     13181 lines in 144 files changed: 5784 ins; 5349 del; 2048 mod

8327476: Upgrade JLine to 3.26.1

Reviewed-by: ihse, vromero

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

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

From prappo at openjdk.org  Thu May  9 14:23:37 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 14:23:37 GMT
Subject: RFR: 8305457: Implement java.io.IO [v5]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <Qw2fiJiRTaqkuevgw1OTRd75A8IByv5gQG-aMX7bp4c=.a9a521c6-0e33-4df8-bd59-dc33533cd29d@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with five additional commits since the last revision:

 - Simplify output.exp
 - Cover null prompt in input tests
 - Make input test parametric
 - Specify behaviour in regard to null
 - Add explicit @throws IOError to IO methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/80eacf8c..401d8d25

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

  Stats: 70 lines in 8 files changed: 31 ins; 14 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From jjg at openjdk.org  Thu May  9 14:43:55 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 9 May 2024 14:43:55 GMT
Subject: RFR: 8305457: Implement java.io.IO [v5]
In-Reply-To: <Qw2fiJiRTaqkuevgw1OTRd75A8IByv5gQG-aMX7bp4c=.a9a521c6-0e33-4df8-bd59-dc33533cd29d@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <Qw2fiJiRTaqkuevgw1OTRd75A8IByv5gQG-aMX7bp4c=.a9a521c6-0e33-4df8-bd59-dc33533cd29d@github.com>
Message-ID: <Q0hJrILTcEkAmGsQuCHs3J5bBpOT0pcdcCGhG98Ah7I=.0431505f-d89d-4a35-8662-9bf3c083492e@github.com>

On Thu, 9 May 2024 14:23:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - Specify behaviour in regard to null
>  - Add explicit @throws IOError to IO methods

(Minor). at least within the context of this PR, tags like `@param` and `@throws` are stylistically inconsistent as to whether they begin with a capital letter and end with a period.  (I have not checked for local consistency within the affected files.)

test/jdk/java/io/IO/IO.java line 125:

> 123:      * To simulate a terminal, the test currently uses the EXPECT(1) Unix
> 124:      * command, which does not work for Windows. Later, a library like pty4j
> 125:      * or JPty might be used instead EXPECT, to cover both Unix and Windows.

Possible missing word `of`: `instead of EXPECT`

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

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2048123137
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1595543569

From prappo at openjdk.org  Thu May  9 16:00:10 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 16:00:10 GMT
Subject: RFR: 8305457: Implement java.io.IO [v6]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <MJ2tnXZIPclfljXMK8t9ql_-zzLyAXk0Z0Gj0RbrYqY=.f2493ee4-b85d-47b0-9e16-d3ab4fd6226f@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo 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 12 additional commits since the last revision:

 - Fix typo
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Simplify output.exp
 - Cover null prompt in input tests
 - Make input test parametric
 - Specify behaviour in regard to null
 - Add explicit @throws IOError to IO methods
 - Specify charset of java.io.IO
 - Use system-dependent line separator for Console.println
 - Strengthen tests after 8330998
   
   https://github.com/openjdk/jdk/pull/18996 now allows us to test
   Console IO better.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/36cfe706...46a7af1f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/401d8d25..46a7af1f

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

  Stats: 16584 lines in 272 files changed: 8281 ins; 5856 del; 2447 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From prappo at openjdk.org  Thu May  9 16:00:10 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 16:00:10 GMT
Subject: RFR: 8305457: Implement java.io.IO [v5]
In-Reply-To: <Q0hJrILTcEkAmGsQuCHs3J5bBpOT0pcdcCGhG98Ah7I=.0431505f-d89d-4a35-8662-9bf3c083492e@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <Qw2fiJiRTaqkuevgw1OTRd75A8IByv5gQG-aMX7bp4c=.a9a521c6-0e33-4df8-bd59-dc33533cd29d@github.com>
 <Q0hJrILTcEkAmGsQuCHs3J5bBpOT0pcdcCGhG98Ah7I=.0431505f-d89d-4a35-8662-9bf3c083492e@github.com>
Message-ID: <pW2RrXA1nsGMUY08ovcCQtaU7NSrs2N-1edD9qvMO5s=.2e8a6029-5d78-4ce7-93dc-630cc948c0bd@github.com>

On Thu, 9 May 2024 14:41:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> (Minor). at least within the context of this PR, tags like `@param` and `@throws` are stylistically inconsistent as to whether they begin with a capital letter and end with a period. (I have not checked for local consistency within the affected files.)

I know, thanks. That was on purpose to mimic the prevailing style of `Console`, just like you assumed in parentheses. Note, like-named methods in `IO` are styled differently.

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

PR Comment: https://git.openjdk.org/jdk/pull/19112#issuecomment-2102944256

From prappo at openjdk.org  Thu May  9 18:27:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 May 2024 18:27:08 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

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

  Fix System.console().readln(null) in jshell
  
  Without it, jshell hangs on me. Will think of a test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/46a7af1f..1bf7a4cd

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

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

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

From duke at openjdk.org  Fri May 10 01:59:12 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 10 May 2024 01:59:12 GMT
Subject: RFR: 8332014: Fix `@since` tags in `jdk.jshell`
Message-ID: <EEVWpO4_ntUkpN3GbUMBSKPJ5q9KPCEQmFazVlNecTc=.97af6015-1c8a-4a9f-b869-a99adfaa979a@github.com>

Please review this small change that aims to make the `@since` in this module more accurate, these bugs were reported by the checker tool at #18934 

-field: jdk.jshell.Snippet.SubKind:RECORD_SUBKIND
This should have `@since` 17 as it was a Preview element in JDK 14-16

-method: java.util.List jdk.jshell.SourceCodeAnalysis.sourceToSnippets(java.lang.String)
-method: int jdk.jshell.tool.JavaShellToolBuilder.start(java.lang.String[])

both should have `@since` 10 instead of 9

Thanks

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

Commit messages:
 - add `@since` tags

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

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

From duke at openjdk.org  Fri May 10 02:25:26 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 10 May 2024 02:25:26 GMT
Subject: RFR: 8332014: Fix `@since` tags in `jdk.jshell` [v2]
In-Reply-To: <EEVWpO4_ntUkpN3GbUMBSKPJ5q9KPCEQmFazVlNecTc=.97af6015-1c8a-4a9f-b869-a99adfaa979a@github.com>
References: <EEVWpO4_ntUkpN3GbUMBSKPJ5q9KPCEQmFazVlNecTc=.97af6015-1c8a-4a9f-b869-a99adfaa979a@github.com>
Message-ID: <BIkUHfaQncAbpj_gqToVnwqZfwcoPdkXM2VdYtEBSzU=.43cd78a2-79fd-4d35-b3e9-6e1693c30bc7@github.com>

> Please review this small change that aims to make the `@since` in this module more accurate, these bugs were reported by the checker tool at #18934 
> 
> -field: jdk.jshell.Snippet.SubKind:RECORD_SUBKIND
> This should have `@since` 17 as it was a Preview element in JDK 14-16
> 
> -method: java.util.List jdk.jshell.SourceCodeAnalysis.sourceToSnippets(java.lang.String)
> -method: int jdk.jshell.tool.JavaShellToolBuilder.start(java.lang.String[])
> 
> both should have `@since` 10 instead of 9
> 
> Thanks

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

  update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19166/files
  - new: https://git.openjdk.org/jdk/pull/19166/files/2e11f9b7..0145bfd6

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

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

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

From smarks at openjdk.org  Fri May 10 04:54:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 10 May 2024 04:54:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
Message-ID: <CNMJuNb-hHUTZbam6PVMXQH-eGKII4k_LohM7GhSg7k=.f9d687a6-1da1-46c3-a226-4e29665f9617@github.com>

On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix System.console().readln(null) in jshell
>   
>   Without it, jshell hangs on me. Will think of a test.

Marked as reviewed by smarks (Reviewer).

Latest changes look good.

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

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2049241670
PR Comment: https://git.openjdk.org/jdk/pull/19112#issuecomment-2103859341

From pminborg at openjdk.org  Fri May 10 07:26:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 10 May 2024 07:26:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
Message-ID: <h8rrzx8ViVaY0Ciu1J6ZLVsV1Irn2i1Ek7TZ2R66GWI=.e1583e64-a7ae-411b-9fb2-a976287cc355@github.com>

On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix System.console().readln(null) in jshell
>   
>   Without it, jshell hangs on me. Will think of a test.

src/java.base/share/classes/java/io/IO.java line 47:

> 45: 
> 46:     private IO() {
> 47:         throw new Error("no instances");

Is this necessary?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596370177

From jpai at openjdk.org  Fri May 10 07:35:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 10 May 2024 07:35:06 GMT
Subject: RFR: 8305457: Implement java.io.IO [v4]
In-Reply-To: <wqdl7WD8hTx1IlgxXylCd053e_MrKw0zrHKC2fwUusM=.b5072cb6-85b7-46c8-9ebd-119a63ec029b@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <wqdl7WD8hTx1IlgxXylCd053e_MrKw0zrHKC2fwUusM=.b5072cb6-85b7-46c8-9ebd-119a63ec029b@github.com>
Message-ID: <u1adSAVgMNh12OxG22cCTxPZiKjpKu6JMkXVEk-Nc0g=.e16a4811-11bb-4e95-8886-e6ab1a4ff13b@github.com>

On Wed, 8 May 2024 18:43:41 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Specify charset of java.io.IO
>  - Use system-dependent line separator for Console.println

src/java.base/share/classes/java/io/IO.java line 38:

> 36:  * had been called on that console.
> 37:  *
> 38:  * <p> Output from methods in this class uses the character set of the system

Hello Pavel, given that `java.io.IO` exposes both input and output methods and the Charset will be used by both input and output, I think we might have to reword this sentence to make a note of input too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596380347

From pminborg at openjdk.org  Fri May 10 07:35:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 10 May 2024 07:35:06 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <mmUl8dkLjrfAs1utQ0e5zn8Knz2ZV3UzM8x4KxB4wtc=.c95890ba-267d-4c0f-8351-4d78cee2f024@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
 <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>
 <mmUl8dkLjrfAs1utQ0e5zn8Knz2ZV3UzM8x4KxB4wtc=.c95890ba-267d-4c0f-8351-4d78cee2f024@github.com>
Message-ID: <k1XL9rhR00IEZIYFMOKXZYhLi0wh5yXLlRGBS9nppTo=.5d6fc4ee-f0cd-4a60-9825-2eefb17eabaf@github.com>

On Tue, 7 May 2024 20:23:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> Should this be final?
>> 
>> With only the private constructor, it doesn't matter too much in practice, but an explicit `final` would be good documentation if that is the intent.
>
> If the sole constructor of a class is private, not only does it preclude the class from being instantiated, but it also precludes the class from being extended. Mind you, even with the sole private constructor, both instantiation and extension are still possible from inside the class or its nested classes. As long as we don't leak such instances to API clients, they won't seem to be able to observe any difference between "the private constructor" and "the private constructor of a final class".
> 
> I think that just having that constructor private but the class "non-final" makes bigger bang for the buck. We can defer the decision to make the class final.
> 
> If this helps, here are a few well-known similar classes:
> 
>   - java.util.Collections
>   - java.util.concurrent.Executors

Although true (and also described in Item 4 in "Effective Java" 3rd ed by JB) I think it is better to also signal the intent by marking the class as `final`. See for example Arrays that we updated some time ago.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596377720

From jpai at openjdk.org  Fri May 10 07:48:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 10 May 2024 07:48:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
Message-ID: <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>

On Thu, 9 May 2024 18:27:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix System.console().readln(null) in jshell
>   
>   Without it, jshell hangs on me. Will think of a test.

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 61:

> 59:     @Override
> 60:     public JdkConsole println(Object obj) {
> 61:         pw.println(obj);

Are these `println(...)` and `print(...)` methods intentionally not using a `writeLock` unlike the `readln(...)` and `readLine(...)` methods which do use (read and write) locks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596392802

From prappo at openjdk.org  Fri May 10 10:25:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 10:25:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <k1XL9rhR00IEZIYFMOKXZYhLi0wh5yXLlRGBS9nppTo=.5d6fc4ee-f0cd-4a60-9825-2eefb17eabaf@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <-WNQ0gigYgjDdjH55OM-8aWzcDeHcA5ORdsK8MpSvj8=.8fe3c2ee-f30b-4dbd-a9a6-b0c8a4f0dbbc@github.com>
 <VeykkrIb_1RvBlQ3NYZJIvig16qeKByY6hcRtpyeruw=.833c60ab-f4a7-4161-a071-ef9ba3b57657@github.com>
 <mmUl8dkLjrfAs1utQ0e5zn8Knz2ZV3UzM8x4KxB4wtc=.c95890ba-267d-4c0f-8351-4d78cee2f024@github.com>
 <k1XL9rhR00IEZIYFMOKXZYhLi0wh5yXLlRGBS9nppTo=.5d6fc4ee-f0cd-4a60-9825-2eefb17eabaf@github.com>
Message-ID: <g7zBOUGHzFfWGH3gNZYZjg6AGIWY0EhKSK5SAsJ4ocM=.33801489-ae59-46ce-826e-57a122c9c065@github.com>

On Fri, 10 May 2024 07:29:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> If the sole constructor of a class is private, not only does it preclude the class from being instantiated, but it also precludes the class from being extended. Mind you, even with the sole private constructor, both instantiation and extension are still possible from inside the class or its nested classes. As long as we don't leak such instances to API clients, they won't seem to be able to observe any difference between "the private constructor" and "the private constructor of a final class".
>> 
>> I think that just having that constructor private but the class "non-final" makes bigger bang for the buck. We can defer the decision to make the class final.
>> 
>> If this helps, here are a few well-known similar classes:
>> 
>>   - java.util.Collections
>>   - java.util.concurrent.Executors
>
> Although true (and also described in Item 4 in "Effective Java" 3rd ed by JB) I think it is better to also signal the intent by marking the class as `final`. See for example Arrays that we updated some time ago.

It feels better to specify what the class is for than to "signal" all the things it is not for. In the first sentence of its documentation comment, `IO` says that it's a "collection of static convenience methods". I'm not sure how a class can signal its intent more clearly than that.

Like that of `Arrays`, `Collections`, `Collectors`, `Comparators`, `Executors`, `Files`, `Objects`, etc., an instance of `IO` or of its subclass is no more useful than an instance of `Object`. Even if `IO` isn't `final` and has a default constructor, it doesn't matter in practice.

Not too far ago, we started generating warnings on default constructors. To avoid those warnings, I had to provide an explicit constructor.

While unnecessary, I'll make `IO` `final`. Maybe it will help an IDE tell the programmer that they are doing something meaningless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596572570

From prappo at openjdk.org  Fri May 10 10:43:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 10:43:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v8]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <GSIOu487zMzbT5rkqhgqPctxxKsS-uj3CWfbmlwdbPs=.b4a2010f-a519-4a0d-8272-31bfd4eb5a6b@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Clarify input charset
 - Make IO final

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/1bf7a4cd..43a95732

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

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

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

From jlahoda at openjdk.org  Fri May 10 11:00:55 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 10 May 2024 11:00:55 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v5]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <WreObvEAFqvbblyLSjrc77L5PA3_TafnEQ4PfjmxbAM=.f73858dc-1502-4edc-8a89-7b7e91149b2f@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

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

  Fixing the '%' prompt problem for JShell tools' console.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19081/files
  - new: https://git.openjdk.org/jdk/pull/19081/files/a138981e..da84810f

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

  Stats: 85 lines in 3 files changed: 82 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19081/head:pull/19081

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

From prappo at openjdk.org  Fri May 10 11:05:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 11:05:06 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <h8rrzx8ViVaY0Ciu1J6ZLVsV1Irn2i1Ek7TZ2R66GWI=.e1583e64-a7ae-411b-9fb2-a976287cc355@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
 <h8rrzx8ViVaY0Ciu1J6ZLVsV1Irn2i1Ek7TZ2R66GWI=.e1583e64-a7ae-411b-9fb2-a976287cc355@github.com>
Message-ID: <lBelQPBR4BCjACmgeZF4hrAnjH9aRmOyeXTqE_9AcPU=.0d7510e0-e0c4-4e56-9c5d-4307469336bb@github.com>

On Fri, 10 May 2024 07:23:38 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix System.console().readln(null) in jshell
>>   
>>   Without it, jshell hangs on me. Will think of a test.
>
> src/java.base/share/classes/java/io/IO.java line 47:
> 
>> 45: 
>> 46:     private IO() {
>> 47:         throw new Error("no instances");
> 
> Is this necessary?

No, it's not necessary.

My guess is that throwing an unconditional error (usually with a snarky message) from the inside the sole private constructor is a historical idiom to deter deep reflectors with their `setAccessible` and what not. Maybe that idiom is outdated with modules and recent efforts on cranking up the [integrity](https://openjdk.org/jeps/8305968), that I don't know.

FWIW, here's a snippet[^*] from "Item 4: Enforce noninstantiability with a private constructor" you referred to in your earlier comment:

> A default constructor is generated only if a class contains no explicit constructors, so a class can be made noninstantiable by including a private constructor:
>
>        // Noninstantiable utility class
>        public class UtilityClass {
>            // Suppress default constructor for noninstantiability
>            private UtilityClass() {
>                throw new AssertionError();
>            }
>            ...  // Remainder omitted
>        }
>
> Because the explicit constructor is private, it is inaccessible outside of the class. The `AssertionError` isn?t strictly required, but it provides insurance in case the constructor is accidentally invoked from within the class. It guarantees the class will never be instantiated under any circumstances.

[^*]: I created that snippet from the second edition, whose page 19 is conveniently publicly available here: https://www.google.ie/books/edition/Effective_Java/ka2VUBqHiWkC?hl=en&gbpv=1&dq=Item+4:+Enforce+noninstantiability+with+a+private+constructor&pg=PA19&printsec=frontcover

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596615677

From prappo at openjdk.org  Fri May 10 14:57:15 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 10 May 2024 14:57:15 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
 <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>
Message-ID: <6ztBTdtAQJwnROJ5Q_B2Qrx8GflN4shNjcXTfpg0w_Y=.fbba516c-bc36-4b2b-8ae7-7ee3d4219674@github.com>

On Fri, 10 May 2024 07:45:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix System.console().readln(null) in jshell
>>   
>>   Without it, jshell hangs on me. Will think of a test.
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 61:
> 
>> 59:     @Override
>> 60:     public JdkConsole println(Object obj) {
>> 61:         pw.println(obj);
> 
> Are these `println(...)` and `print(...)` methods intentionally not using a `writeLock` unlike the `readln(...)` and `readLine(...)` methods which do use (read and write) locks?

When implementing, I asked myself if I must use any of those monitors and decided that I don't have to. My reasoning is below.

`readLock`:

- is used inside the object that `Reader reader` is initialised with, and

- it also guards fields such as `char[] rcb`, `boolean restoreEcho` and `boolean shutdownHookInstalled`.

Since `println` and `print` don't call methods on `reader` or access the above fields, they don't require `readLock`.

`writeLock`:

- is used inside objects that `Writer out` and `PrintWriter pw` are initialised with, and
- also in compound operations that first write and then immediately read. (I assume, it's so that no concurrent write could sneak in between writing and reading parts of such a compound.)

`println` or `print` don't call methods on `out` and certainly don't do any write-read compounds. That said, they call methods on `pw`. But `pw` uses `writeLock` internally. So in that sense we're covered. 

One potential concern is a write-write compound in `print`:


    @Override
    public JdkConsole print(Object obj) {
        pw.print(obj);
        pw.flush(); // automatic flushing does not cover print
        return this;
    }


I'm saying write-_write_, not write-_flush_, because as far as synchronisation is concerned,  `pw.flush()` should behave the same as `pw.print("")`.

While not using `writeLock` is not strictly correct, I believe the potential execution interleavings with other writes are benign. What's the worst that could happen? You flush more than you expected? Big deal!

Since we exhausted all the reasons to use `writeLock`, I don't think we need one.



Naoto has already reviewed this PR with only minor comments. While that increases my confidence in that the implementation is correct, it doesn't hurt to request re-review of this specific part: @naotoj, do you think I should use any of those monitors?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596861708

From asotona at openjdk.org  Fri May 10 15:09:11 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 May 2024 15:09:11 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v5]
In-Reply-To: <WreObvEAFqvbblyLSjrc77L5PA3_TafnEQ4PfjmxbAM=.f73858dc-1502-4edc-8a89-7b7e91149b2f@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <WreObvEAFqvbblyLSjrc77L5PA3_TafnEQ4PfjmxbAM=.f73858dc-1502-4edc-8a89-7b7e91149b2f@github.com>
Message-ID: <gjOcQPKUvaSHVPF1aO732h5XXFC4X_tNod1RWJjDH-E=.57ae7f64-58c3-48a9-af1a-194d770f9ba6@github.com>

On Fri, 10 May 2024 11:00:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing the '%' prompt problem for JShell tools' console.

test/jdk/java/io/Console/ConsolePromptTest.java line 30:

> 28:  * @library /test/lib
> 29:  * @run main/othervm --limit-modules java.base ConsolePromptTest
> 30:  * @run main/othervm -Djdk.console=java.base java.base ConsolePromptTest

Suggestion:

 * @run main/othervm -Djdk.console=java.base ConsolePromptTest

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19081#discussion_r1596875588

From jlahoda at openjdk.org  Fri May 10 15:34:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 10 May 2024 15:34:27 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v6]
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <SM5z0EXCWQaQUP4ug3zg6piECoA9He1YTMxgnNBVLTk=.278a876f-b9eb-4eea-b89d-e53d3ca718ea@github.com>

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

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

  Update test/jdk/java/io/Console/ConsolePromptTest.java
  
  Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19081/files
  - new: https://git.openjdk.org/jdk/pull/19081/files/da84810f..441bdad8

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

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

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

From asotona at openjdk.org  Fri May 10 15:34:27 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 May 2024 15:34:27 GMT
Subject: RFR: 8331535: Incorrect prompt for Console.readLine [v6]
In-Reply-To: <SM5z0EXCWQaQUP4ug3zg6piECoA9He1YTMxgnNBVLTk=.278a876f-b9eb-4eea-b89d-e53d3ca718ea@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
 <SM5z0EXCWQaQUP4ug3zg6piECoA9He1YTMxgnNBVLTk=.278a876f-b9eb-4eea-b89d-e53d3ca718ea@github.com>
Message-ID: <qH1jZckpU9hXkUvYW5doTmDlgQuq3nG5u2EMDReuhqk=.f2ac2d33-abd2-48ef-9213-4d5399e08149@github.com>

On Fri, 10 May 2024 15:32:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
>> 
>> System.console().readLine("%%s");
>> 
>> 
>> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/io/Console/ConsolePromptTest.java
>   
>   Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19081#pullrequestreview-2050327444

From naoto at openjdk.org  Fri May 10 16:44:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 10 May 2024 16:44:12 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <6ztBTdtAQJwnROJ5Q_B2Qrx8GflN4shNjcXTfpg0w_Y=.fbba516c-bc36-4b2b-8ae7-7ee3d4219674@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
 <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>
 <6ztBTdtAQJwnROJ5Q_B2Qrx8GflN4shNjcXTfpg0w_Y=.fbba516c-bc36-4b2b-8ae7-7ee3d4219674@github.com>
Message-ID: <t25BDNnhk-6FuZwRF_6j3xNfkNGdNMeAcZdhGbaTW_k=.630978f0-9f05-462d-a97c-dbb57d26c936@github.com>

On Fri, 10 May 2024 14:54:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 61:
>> 
>>> 59:     @Override
>>> 60:     public JdkConsole println(Object obj) {
>>> 61:         pw.println(obj);
>> 
>> Are these `println(...)` and `print(...)` methods intentionally not using a `writeLock` unlike the `readln(...)` and `readLine(...)` methods which do use (read and write) locks?
>
> When implementing, I asked myself if I must use any of those monitors and decided that I don't have to. My reasoning is below.
> 
> `readLock`:
> 
> - is used inside the object that `Reader reader` is initialised with, and
> 
> - it also guards fields such as `char[] rcb`, `boolean restoreEcho` and `boolean shutdownHookInstalled`.
> 
> Since `println` and `print` don't call methods on `reader` or access the above fields, they don't require `readLock`.
> 
> `writeLock`:
> 
> - is used inside objects that `Writer out` and `PrintWriter pw` are initialised with, and
> - also in compound operations that first write and then immediately read. (I assume, it's so that no concurrent write could sneak in between writing and reading parts of such a compound.)
> 
> `println` or `print` don't call methods on `out` and certainly don't do any write-read compounds. That said, they call methods on `pw`. But `pw` uses `writeLock` internally. So in that sense we're covered. 
> 
> One potential concern is a write-write compound in `print`:
> 
> 
>     @Override
>     public JdkConsole print(Object obj) {
>         pw.print(obj);
>         pw.flush(); // automatic flushing does not cover print
>         return this;
>     }
> 
> 
> I'm saying write-_write_, not write-_flush_, because as far as synchronisation is concerned,  `pw.flush()` should behave the same as `pw.print("")`.
> 
> While not using `writeLock` is not strictly correct, I believe the potential execution interleavings with other writes are benign. What's the worst that could happen? You flush more than you expected? Big deal!
> 
> Since we exhausted all the reasons to use `writeLock`, I don't think we need one.
> 
> 
> 
> Naoto has already reviewed this PR with only minor comments. While that increases my confidence in that the implementation is correct, it doesn't hurt to request re-review of this specific part: @naotoj, do you think I should use any of those monitors?

I think your investigation is correct. As to the write-write case, there already is the same pattern in (`formatter` basically utilizes `pw` underneath) 

    public JdkConsole format(String fmt, Object ... args) {
        formatter.format(fmt, args).flush();
        return this;
    }

So I think it is acceptable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1596976499

From jlahoda at openjdk.org  Mon May 13 08:19:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 13 May 2024 08:19:16 GMT
Subject: Integrated: 8331535: Incorrect prompt for Console.readLine
In-Reply-To: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
References: <IQvUAYG5zj0JqUbWiQiryAuBrtV6jrVCvy9useQZmlc=.a4dd8dfc-e835-4405-83f8-fd1bda8480f6@github.com>
Message-ID: <QNbMvTXgnwCWrjAtSFJEDSQeQGjvhb8QU_DiTSJNSwo=.e90590b6-aacb-4bae-bfa9-fdf6a2eda631@github.com>

On Fri, 3 May 2024 10:11:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JLine reads a line, there may be a prompt provided. However, JLine will not interpret the prompt literally, it will handle `%` specially. As a consequence, doing:
> 
> System.console().readLine("%%s");
> 
> 
> will not print `%s`, as first `String.format` is used, which will convert `%%s` to `%s`, and then JLine will interpret the `%`. The proposed solution is to duplicate the `%`, so that JLine will print it.

This pull request has now been integrated.

Changeset: 5a8df410
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a8df4106ac5386eb72e874dcadf2b18defe27d8
Stats:     296 lines in 6 files changed: 291 ins; 0 del; 5 mod

8331535: Incorrect prompt for Console.readLine
8331681: Test that jdk.internal.io.JdkConsole does not interpret prompts

Reviewed-by: naoto, asotona

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

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

From prappo at openjdk.org  Mon May 13 09:56:35 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 May 2024 09:56:35 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo 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 17 additional commits since the last revision:

 - Escape prompt
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Clarify input charset
 - Make IO final
 - Fix System.console().readln(null) in jshell
   
   Without it, jshell hangs on me. Will think of a test.
 - Fix typo
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Simplify output.exp
 - Cover null prompt in input tests
 - Make input test parametric
 - ... and 7 more: https://git.openjdk.org/jdk/compare/5ac71ae9...17100ab8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/43a95732..17100ab8

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

  Stats: 3238 lines in 113 files changed: 2069 ins; 612 del; 557 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From hgreule at openjdk.org  Mon May 13 10:38:05 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 13 May 2024 10:38:05 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v2]
In-Reply-To: <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
Message-ID: <RbqZFfVR-yW2ooMXMdD5bXXhXG2cQ5jHxbWx-iEn6TM=.1dde3486-1169-4c28-aa15-d99c8da857d6@github.com>

On Thu, 28 Mar 2024 08:37:00 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Pasting  e.g.
>> 
>> I m(I i, int x) {
>>    return switch (x) {
>>         default -> i;
>>    };
>> }
>> 
>> in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch.
>> 
>> Javac will not crash but swallow the exception, and create a file containing the command line options.
>> 
>> I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally.
>
> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash
>  - add bug id
>  - Fix jshell crash on unknown type in switch yield

Hi, could someone please help review this change? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18383#issuecomment-2107225861

From jpai at openjdk.org  Mon May 13 10:52:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 10:52:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
Message-ID: <FToruFbQiqKRPKZRsaSau6GAb7tH7_5sCUm7xa-_l5s=.eb4bdb9c-e3eb-4709-bf13-66f1bc6c4801@github.com>

On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo 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 17 additional commits since the last revision:
> 
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/ea3ed865...17100ab8

The latest updated state of this PR looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2052345767

From jpai at openjdk.org  Mon May 13 10:52:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 13 May 2024 10:52:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v7]
In-Reply-To: <t25BDNnhk-6FuZwRF_6j3xNfkNGdNMeAcZdhGbaTW_k=.630978f0-9f05-462d-a97c-dbb57d26c936@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <554HmRIAD_1Hf8Hbq6_YRH9iTf8fBk_OZ1XrlmSsQAU=.90c8b148-029a-429f-9037-179d9d30f6ad@github.com>
 <qDUNtEpZzW7nx2tzrSvzxei_AbLxXwyKFGEMZk5OpxI=.1fcd778a-1d52-40e0-944b-8d1a26bd7c8e@github.com>
 <6ztBTdtAQJwnROJ5Q_B2Qrx8GflN4shNjcXTfpg0w_Y=.fbba516c-bc36-4b2b-8ae7-7ee3d4219674@github.com>
 <t25BDNnhk-6FuZwRF_6j3xNfkNGdNMeAcZdhGbaTW_k=.630978f0-9f05-462d-a97c-dbb57d26c936@github.com>
Message-ID: <O9wqX8jU_OAAWbqskb3IQogIsZ0D-LC-FuMeniRm7Go=.186b07b3-3da7-4474-b17c-0237111e076c@github.com>

On Fri, 10 May 2024 16:41:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> When implementing, I asked myself if I must use any of those monitors and decided that I don't have to. My reasoning is below.
>> 
>> `readLock`:
>> 
>> - is used inside the object that `Reader reader` is initialised with, and
>> 
>> - it also guards fields such as `char[] rcb`, `boolean restoreEcho` and `boolean shutdownHookInstalled`.
>> 
>> Since `println` and `print` don't call methods on `reader` or access the above fields, they don't require `readLock`.
>> 
>> `writeLock`:
>> 
>> - is used inside objects that `Writer out` and `PrintWriter pw` are initialised with, and
>> - also in compound operations that first write and then immediately read. (I assume, it's so that no concurrent write could sneak in between writing and reading parts of such a compound.)
>> 
>> `println` or `print` don't call methods on `out` and certainly don't do any write-read compounds. That said, they call methods on `pw`. But `pw` uses `writeLock` internally. So in that sense we're covered. 
>> 
>> One potential concern is a write-write compound in `print`:
>> 
>> 
>>     @Override
>>     public JdkConsole print(Object obj) {
>>         pw.print(obj);
>>         pw.flush(); // automatic flushing does not cover print
>>         return this;
>>     }
>> 
>> 
>> I'm saying write-_write_, not write-_flush_, because as far as synchronisation is concerned,  `pw.flush()` should behave the same as `pw.print("")`.
>> 
>> While not using `writeLock` is not strictly correct, I believe the potential execution interleavings with other writes are benign. What's the worst that could happen? You flush more than you expected? Big deal!
>> 
>> Since we exhausted all the reasons to use `writeLock`, I don't think we need one.
>> 
>> 
>> 
>> Naoto has already reviewed this PR with only minor comments. While that increases my confidence in that the implementation is correct, it doesn't hurt to request re-review of this specific part: @naotoj, do you think I should use any of those monitors?
>
> I think your investigation is correct. As to the write-write case, there already is the same pattern in (`formatter` basically utilizes `pw` underneath) 
> 
>     public JdkConsole format(String fmt, Object ... args) {
>         formatter.format(fmt, args).flush();
>         return this;
>     }
> 
> So I think it is acceptable.

Thank you for that explanation, Pavel. I think the crucial detail happens to be:

> But pw uses writeLock internally. So in that sense we're covered.

As you note, the same instance of `writeLock` will get used internally by the `PrintWriter`, so I think the current version of this code is good and won't require additionally locking in the outer code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1598268588

From prappo at openjdk.org  Mon May 13 12:59:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 May 2024 12:59:08 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
 <6PQqK1kADFKALT6GNcnAiRvM1TykSgCTK5m84MRscIE=.538243ee-787b-45ae-8b0e-44cca343ebc9@github.com>
Message-ID: <Bs24lao4Q9KgrEy0OT7WG_Y_79LTVcLSXYZ7Xz27xi8=.6c24caf8-9ff3-43ab-ad9c-1694dd624caf@github.com>

On Thu, 9 May 2024 08:18:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.
>
> src/java.base/share/man/java.1 line 3856:
> 
>> 3854: .SH REMOVED JAVA OPTIONS
>> 3855: .PP
>> 3856: These \f[V]java\f[R] options have been removed in JDK 24 and using them
> 
> This is incorrect. You can't just change 23 to 24 here as the actual set of flags listed below will be will be different.

David, my understanding is that you agree that this is okay (per our out-of-band, follow-up discussion).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19119#discussion_r1598432769

From smarks at openjdk.org  Tue May 14 01:18:09 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 14 May 2024 01:18:09 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
Message-ID: <ZOkaZFGimKmYSgRQOmzQfCXRWkUp2FJqGv8JC-e6UGY=.16ccd575-f387-4085-999e-16bdd7bd2864@github.com>

On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo 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 17 additional commits since the last revision:
> 
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8b9c719f...17100ab8

Marked as reviewed by smarks (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2054056729

From pminborg at openjdk.org  Tue May 14 14:30:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 14 May 2024 14:30:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
Message-ID: <kavKbw2Sl0yLDl8CD8AZBMAdYgtyfmHrQIoWNRs7FCk=.330c7414-67b0-4b34-90e9-d9d7a9df2743@github.com>

On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo 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 17 additional commits since the last revision:
> 
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/2f44ac18...17100ab8

src/java.base/share/classes/java/io/IO.java line 98:

> 96:      *                 or if an I/O error occurs
> 97:      */
> 98:     public static String readln(String prompt) {

Did we consider Optional<String> here? Maybe that is to complicated for an onramp?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1600145844

From prappo at openjdk.org  Tue May 14 14:34:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 14:34:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <kavKbw2Sl0yLDl8CD8AZBMAdYgtyfmHrQIoWNRs7FCk=.330c7414-67b0-4b34-90e9-d9d7a9df2743@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
 <kavKbw2Sl0yLDl8CD8AZBMAdYgtyfmHrQIoWNRs7FCk=.330c7414-67b0-4b34-90e9-d9d7a9df2743@github.com>
Message-ID: <CfFNZGzpYR425wA4ORYI7Xi2onIZjiBUw5L97w2KkUc=.532cdbec-1cc1-456c-ae35-15052f62c97f@github.com>

On Tue, 14 May 2024 14:27:35 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Pavel Rappo 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 17 additional commits since the last revision:
>> 
>>  - Escape prompt
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>  - Clarify input charset
>>  - Make IO final
>>  - Fix System.console().readln(null) in jshell
>>    
>>    Without it, jshell hangs on me. Will think of a test.
>>  - Fix typo
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>  - Simplify output.exp
>>  - Cover null prompt in input tests
>>  - Make input test parametric
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/63e13e69...17100ab8
>
> src/java.base/share/classes/java/io/IO.java line 98:
> 
>> 96:      *                 or if an I/O error occurs
>> 97:      */
>> 98:     public static String readln(String prompt) {
> 
> Did we consider Optional<String> here? Maybe that is to complicated for an onramp?

Have we considered it? Yes, momentarily. Will we implement it here? No, certainly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1600152722

From naoto at openjdk.org  Tue May 14 16:29:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 16:29:29 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v5]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <C-orD4cxIFTkMl5NE1bSaXM8ohmMQmu3D29hwk3MHKg=.39632137-be83-4804-820b-b191ecbbfc9d@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

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

 - Merge branch 'master' into JDK-8330276-Console-with-explicit-Locale
 - Removed JdkConsole.printf()
 - Addresses a CSR review comment
 - Merge branch 'master' into JDK-8330276-Console-with-explicit-Locale
 - Addressed review comments
 - Not using System.err
 - spacing
 - initial commit

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

Changes: https://git.openjdk.org/jdk/pull/18923/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18923&range=04
  Stats: 438 lines in 7 files changed: 335 ins; 24 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/18923.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18923/head:pull/18923

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

From prappo at openjdk.org  Tue May 14 21:41:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 21:41:13 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <dyGsHe50-9tsvxAgjvkSEgeMxpWfBIcxbHry9HXI3MI=.3bf65598-5584-4794-a502-3e0925fe1710@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

Withdrawing this, as a different approach is required.

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

PR Comment: https://git.openjdk.org/jdk/pull/19119#issuecomment-2111182078

From prappo at openjdk.org  Tue May 14 21:41:13 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 May 2024 21:41:13 GMT
Subject: Withdrawn: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
References: <6tFYXJ753At7nUZTy8khVVeiQHYtZRBRYegXSTXViUY=.f3110151-9ea0-4b55-89f1-90039273fd34@github.com>
Message-ID: <3IfStE5WvNR62yu4s0sbkQWZ9TWw3UIrXILYhrHdlc4=.dcfd1934-f44f-4f79-9fb6-4b87bd6679ea@github.com>

On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this mechanical change to man pages. This PR should be integrated after https://github.com/openjdk/jdk/pull/18787.

This pull request has been closed without being integrated.

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

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

From naoto at openjdk.org  Tue May 14 22:40:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 May 2024 22:40:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
Message-ID: <I485KtM4-m_jFq9CZ0UMBawk_V547GaFQBi7cSw7HGg=.c9034bb2-a954-4f03-9751-0e8e7d667daa@github.com>

On Mon, 13 May 2024 09:56:35 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo 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 17 additional commits since the last revision:
> 
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Simplify output.exp
>  - Cover null prompt in input tests
>  - Make input test parametric
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/42e6a104...17100ab8

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2056583806

From liach at openjdk.org  Tue May 14 23:26:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 May 2024 23:26:03 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v2]
In-Reply-To: <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
Message-ID: <cl7h5yqEsXoCD6CDspJYJRSRIa7kr5cPokctxf-ymbM=.79adf625-8e60-47bc-9cf6-7174d86c6f1f@github.com>

On Thu, 28 Mar 2024 08:37:00 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Pasting  e.g.
>> 
>> I m(I i, int x) {
>>    return switch (x) {
>>         default -> i;
>>    };
>> }
>> 
>> in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch.
>> 
>> Javac will not crash but swallow the exception, and create a file containing the command line options.
>> 
>> I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally.
>
> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash
>  - add bug id
>  - Fix jshell crash on unknown type in switch yield

@vicente-romero-oracle Is it possible for you to quickly review this bugfix?

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

PR Comment: https://git.openjdk.org/jdk/pull/18383#issuecomment-2111317953

From smarks at openjdk.org  Wed May 15 00:05:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 15 May 2024 00:05:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v9]
In-Reply-To: <CfFNZGzpYR425wA4ORYI7Xi2onIZjiBUw5L97w2KkUc=.532cdbec-1cc1-456c-ae35-15052f62c97f@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <PIg24sny09iDwNT6W--TkoqtY8V2tXWCjrUL4MO-CRg=.67519d97-15b9-4b72-9bdc-ecbcc3dbfd5c@github.com>
 <kavKbw2Sl0yLDl8CD8AZBMAdYgtyfmHrQIoWNRs7FCk=.330c7414-67b0-4b34-90e9-d9d7a9df2743@github.com>
 <CfFNZGzpYR425wA4ORYI7Xi2onIZjiBUw5L97w2KkUc=.532cdbec-1cc1-456c-ae35-15052f62c97f@github.com>
Message-ID: <cwk4-rcAd-hvQ4e6Rzo3-puG_b4RQc1FZyJsUedRKTw=.45441623-6f70-4850-9bae-7fc4662fa50c@github.com>

On Tue, 14 May 2024 14:31:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/IO.java line 98:
>> 
>>> 96:      *                 or if an I/O error occurs
>>> 97:      */
>>> 98:     public static String readln(String prompt) {
>> 
>> Did we consider Optional<String> here? Maybe that is to complicated for an onramp?
>
> Have we considered it? Yes, momentarily. Will we implement it here? No, certainly.

The precedent to return `null` from something that reads a line has already been set by `BufferedReader.readLine()` and `Console.readLine()`.

`Optional` is indeed intended for return values but it probably works better for things that are totally new, such as various streams operation (for which `Optional` was introduced), modules, the Classfile API, HTTP client, etc. And to use `Optional` effectively one needs to know how to use lambdas, the teaching of which is probably at odds with the on-ramp story.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1600793369

From naoto at openjdk.org  Wed May 15 16:12:33 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 May 2024 16:12:33 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v6]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <wJdAqgZa5QX1hZqIP1wEdFRU4Jijfguf98Jr0OXwjTg=.8c639ea5-4aa6-4b4b-af6d-66b6b9ba8a53@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

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

  Adding workaround to the test due to JLine's questionable behavior

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/6fd17574..cace6171

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

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

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

From acobbs at openjdk.org  Wed May 15 17:03:12 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 15 May 2024 17:03:12 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
Message-ID: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>

When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.

This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

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

Commit messages:
 - Update copyright years.
 - Fix typo in exception message.
 - Add new method JavaShellToolBuilder.windowSize().

Changes: https://git.openjdk.org/jdk/pull/19226/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19226&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332314
  Stats: 46 lines in 4 files changed: 35 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/19226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19226/head:pull/19226

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

From liach at openjdk.org  Wed May 15 17:03:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 May 2024 17:03:13 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <N6ompJy5C2aybkUPUKnmNkk7rvDlPUjGFCCza4emDIw=.f3ec7f04-cc42-4c26-becc-4cda7e91bb5b@github.com>

On Tue, 14 May 2024 02:00:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java line 225:

> 223:             throw new IllegalArgumentException("columns = " + columns);
> 224:         if (rows <= 0)
> 225:             throw new IllegalArgumentException("-columns = " + -columns);

Is this supposed to have a message like `"rows = " + rows` instead

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19226#discussion_r1599307160

From acobbs at openjdk.org  Wed May 15 17:03:13 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 15 May 2024 17:03:13 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <N6ompJy5C2aybkUPUKnmNkk7rvDlPUjGFCCza4emDIw=.f3ec7f04-cc42-4c26-becc-4cda7e91bb5b@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
 <N6ompJy5C2aybkUPUKnmNkk7rvDlPUjGFCCza4emDIw=.f3ec7f04-cc42-4c26-becc-4cda7e91bb5b@github.com>
Message-ID: <ht33I9jtaajZQtK00U9MHL_NBakqKEzHuise9RYpmBs=.671edebe-d6cf-4ce4-a409-7c568b592bd5@github.com>

On Tue, 14 May 2024 02:46:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
>> 
>> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.
>
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java line 225:
> 
>> 223:             throw new IllegalArgumentException("columns = " + columns);
>> 224:         if (rows <= 0)
>> 225:             throw new IllegalArgumentException("-columns = " + -columns);
> 
> Is this supposed to have a message like `"rows = " + rows` instead

Oops, yes - thanks. Fixed in 08f7d3bc069.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19226#discussion_r1600052871

From naoto at openjdk.org  Wed May 15 17:05:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 May 2024 17:05:17 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v7]
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

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

  Reverted test workaround. Fixed JLine (backing out a questionable change)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18923/files
  - new: https://git.openjdk.org/jdk/pull/18923/files/cace6171..7833da36

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

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

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

From jlahoda at openjdk.org  Wed May 15 17:35:07 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 15 May 2024 17:35:07 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v7]
In-Reply-To: <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>
Message-ID: <0StF1k17neSewK67rcoBy9eufUUAMuIzgxNsGtun9ns=.bb9e0c81-2411-4575-bf6d-66397bbe10b6@github.com>

On Wed, 15 May 2024 17:05:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted test workaround. Fixed JLine (backing out a questionable change)

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18923#pullrequestreview-2058627699

From naoto at openjdk.org  Wed May 15 19:31:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 May 2024 19:31:07 GMT
Subject: Integrated: 8330276: Console methods with explicit Locale
In-Reply-To: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
Message-ID: <Wcem1WS5qxBJglpfmOzKiVEl-HVMHOHZmQnb1RKnKBE=.1b0568d8-0e91-452b-b039-3edace08e399@github.com>

On Tue, 23 Apr 2024 20:35:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.

This pull request has now been integrated.

Changeset: 7cff04fc
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7cff04fc8a8114a297437aa526b18b6185831eac
Stats:     441 lines in 8 files changed: 337 ins; 24 del; 80 mod

8330276: Console methods with explicit Locale

Reviewed-by: joehw, rriggs, jlahoda

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

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

From naoto at openjdk.org  Thu May 16 16:30:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 16 May 2024 16:30:08 GMT
Subject: RFR: 8330276: Console methods with explicit Locale [v7]
In-Reply-To: <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>
References: <GT275XVwYlYL3PhYwOTQ_-HwKqp9QYUeIzEIeJKEwkQ=.9a7faf08-8637-45a3-97bd-fd58756a6711@github.com>
 <obT5NKXsV-mvpwqSJxGBtbiGfelyoPuqeGM_SyuFXLc=.aa4fecaf-6788-4d67-a973-86408830c435@github.com>
Message-ID: <IS5XsEslBpuXkKuHaB99K_JrITF6gJwFtGSpyI2K_6c=.408cc252-8091-4e95-9b92-4fc19b6171a8@github.com>

On Wed, 15 May 2024 17:05:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Proposing new overloaded methods in `java.io.Console` class that explicitly take a `Locale` argument. Existing methods rely on the default locale, so the users won't be able to format their prompts/outputs in a certain locale explicitly.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted test workaround. Fixed JLine (backing out a questionable change)

The changeset included a workaround patch to the upstream JLine. An issue for it was created by Jan: https://github.com/jline/jline3/issues/982

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

PR Comment: https://git.openjdk.org/jdk/pull/18923#issuecomment-2115684085

From jlahoda at openjdk.org  Thu May 16 17:04:04 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 16 May 2024 17:04:04 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v2]
In-Reply-To: <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
Message-ID: <YlpaKMg-IYk_42tDX3ho4wO_EJo57rdJVHQOv7Ps-K0=.a93d8e3e-3983-4251-a5a2-4b5398d2a61b@github.com>

On Thu, 28 Mar 2024 08:37:00 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Pasting  e.g.
>> 
>> I m(I i, int x) {
>>    return switch (x) {
>>         default -> i;
>>    };
>> }
>> 
>> in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch.
>> 
>> Javac will not crash but swallow the exception, and create a file containing the command line options.
>> 
>> I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally.
>
> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash
>  - add bug id
>  - Fix jshell crash on unknown type in switch yield

I apologize for a belated reply. I agree with not adding a null check, that is usually a wrong/insufficient approach. And I think I agree with your approach, but I am not sure if it goes far enough.

I think I would try to go with something like:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index d0f3ae7464a..4fe1b4430ec 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -4623,9 +4623,6 @@ Type checkIdInternal(JCTree tree,
                      Type pt,
                      Env<AttrContext> env,
                      ResultInfo resultInfo) {
-            if (pt.isErroneous()) {
-                return types.createErrorType(site);
-            }
             Type owntype; // The computed type of this identifier occurrence.
             switch (sym.kind) {
             case TYP:
@@ -4734,6 +4731,10 @@ else if (ownOuter.hasTag(CLASS) && site != ownOuter) {
                 chk.checkPreview(tree.pos(), env.info.scope.owner, sym);
             }
 
+            if (pt.isErroneous()) {
+                owntype = types.createErrorType(owntype);
+            }
+
             // If symbol is a variable, check that its type and
             // kind are compatible with the prototype and protokind.
             return check(tree, owntype, sym.kind.toSelector(), resultInfo);


I.e., let the `checkIdInternal` run as normally, just wrap the type with an error type. When I ran tests with this change, three failed for me:

FAILED: tools/javac/generics/diamond/7188968/T7188968.java
FAILED: tools/javac/lambda/methodReference/MethodRefToInnerWithoutOuter.java
FAILED: tools/javac/lambda/MethodReference23.java


For the `tools/javac/lambda` tests, the new errors seemed better/more appropriate than the original ones, so those are not a problem I think (but an independent check would be good).

The `tools/javac/generics/diamond/7188968/T7188968.java` is producing more unchecked warnings with that change, and I am not quite sure if that's appropriate.

As for a test - test inside JShell is good, but there should be a test inside somewhere `tools/javac`. A good place might be `test/langtools/tools/javac/recovery/AttrRecovery.java`:

    @Test
    public void testErroneousTarget() throws Exception {
        String code = """
                      public class C {
                          public Undefined g(Undefined u) {
                              return switch (0) {
                                  default -> u;
                              };
                          }
                      }
                      """;
        Path curPath = Path.of(".");
        List<String> actual = new JavacTask(tb)
                .options("-XDrawDiagnostics")
                .sources(code)
                .outdir(curPath)
                .run(Expect.FAIL, 1)
                .writeAll()
                .getOutputLines(OutputKind.DIRECT);

        List<String> expected = List.of(
                "C.java:2:24: compiler.err.cant.resolve.location: kindname.class, Undefined, , , (compiler.misc.location: kindname.class, C, null)",
                "C.java:2:12: compiler.err.cant.resolve.location: kindname.class, Undefined, , , (compiler.misc.location: kindname.class, C, null)",
                "2 errors"
        );

        if (!Objects.equals(actual, expected)) {
            error("Expected: " + expected + ", but got: " + actual);
        }
    }


(Note the explicit use of the expected exit code, which should guard against crashes. An alternative is to use `-XDdev` in the list of parameters, see other tests in the class - that should print the exception if it happens.)

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

PR Comment: https://git.openjdk.org/jdk/pull/18383#issuecomment-2115778378

From jlahoda at openjdk.org  Thu May 16 19:40:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 16 May 2024 19:40:02 GMT
Subject: RFR: 8129418: JShell: better highlighting of errors in imports on
 demand
In-Reply-To: <JvdpMuEPieuMJkI27_pgiFYxoI-8DyP26p0h_q46NLU=.2273a069-2d0f-4542-a962-986d3c6ad503@github.com>
References: <JvdpMuEPieuMJkI27_pgiFYxoI-8DyP26p0h_q46NLU=.2273a069-2d0f-4542-a962-986d3c6ad503@github.com>
Message-ID: <6NoNICvBMyeg4bLzu0SzuoJ3NQS03mWXN8gME56v61U=.7e791a32-9a81-469e-9f6e-bb6ad2d6d8e0@github.com>

On Thu, 2 May 2024 23:42:38 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> When Type-Import-on-Demand fails, we now point the position of the first incorrect PackageOrTypeName which clearly isn't package, a class,or an interface.
> 
> old behavior:
> 
> |  Welcome to JShell -- Version 22.0.1
> |  For an introduction type: /help intro
> 
> jshell> import unknown.*;
> |  Error:
> |  package unknown does not exist
> |  import unknown.*;
> |  ^
> 
> New behavior:
> 
> |  Welcome to JShell -- Version 23-internal
> |  For an introduction type: /help intro
> 
> jshell> import unknown.*;
> |  Error:
> |  package unknown does not exist
> |  import unknown.*;
> |         ^-----^
> 
> 
> 
> jshell> import unknown.unknown.unknown.*;
> |  Error:
> |  package unknown.unknown.unknown does not exist
> |  import unknown.unknown.unknown.*;
> |         ^---------------------^

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19073#pullrequestreview-2061725383

From nbenalla at openjdk.org  Fri May 17 06:43:06 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 17 May 2024 06:43:06 GMT
Subject: Integrated: 8129418: JShell: better highlighting of errors in imports
 on demand
In-Reply-To: <JvdpMuEPieuMJkI27_pgiFYxoI-8DyP26p0h_q46NLU=.2273a069-2d0f-4542-a962-986d3c6ad503@github.com>
References: <JvdpMuEPieuMJkI27_pgiFYxoI-8DyP26p0h_q46NLU=.2273a069-2d0f-4542-a962-986d3c6ad503@github.com>
Message-ID: <p9vx54ZlJkAPWCTL21gmAmReZTyZLktegr8u3_M4xic=.8c5ef846-a443-4032-9b79-96fd00d8b442@github.com>

On Thu, 2 May 2024 23:42:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> When Type-Import-on-Demand fails, we now point the position of the first incorrect PackageOrTypeName which clearly isn't package, a class,or an interface.
> 
> old behavior:
> 
> |  Welcome to JShell -- Version 22.0.1
> |  For an introduction type: /help intro
> 
> jshell> import unknown.*;
> |  Error:
> |  package unknown does not exist
> |  import unknown.*;
> |  ^
> 
> New behavior:
> 
> |  Welcome to JShell -- Version 23-internal
> |  For an introduction type: /help intro
> 
> jshell> import unknown.*;
> |  Error:
> |  package unknown does not exist
> |  import unknown.*;
> |         ^-----^
> 
> 
> 
> jshell> import unknown.unknown.unknown.*;
> |  Error:
> |  package unknown.unknown.unknown does not exist
> |  import unknown.unknown.unknown.*;
> |         ^---------------------^

This pull request has now been integrated.

Changeset: ae999eae
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae999eae7e61072ad964a43f622fa930ce1179f7
Stats:     11 lines in 7 files changed: 0 ins; 1 del; 10 mod

8129418: JShell: better highlighting of errors in imports on demand

Reviewed-by: jlahoda

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

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

From hgreule at openjdk.org  Fri May 17 07:25:06 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Fri, 17 May 2024 07:25:06 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v2]
In-Reply-To: <YlpaKMg-IYk_42tDX3ho4wO_EJo57rdJVHQOv7Ps-K0=.a93d8e3e-3983-4251-a5a2-4b5398d2a61b@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
 <YlpaKMg-IYk_42tDX3ho4wO_EJo57rdJVHQOv7Ps-K0=.a93d8e3e-3983-4251-a5a2-4b5398d2a61b@github.com>
Message-ID: <YEhpagutSzFNM-FBoYcncKKTHn57RJestluPc2iWQeI=.594253f2-3d63-452a-b5b6-71b0cabbc3cc@github.com>

On Thu, 16 May 2024 17:01:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash
>>  - add bug id
>>  - Fix jshell crash on unknown type in switch yield
>
> I apologize for a belated reply. I agree with not adding a null check, that is usually a wrong/insufficient approach. And I think I agree with your approach, but I am not sure if it goes far enough.
> 
> I think I would try to go with something like:
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> index d0f3ae7464a..4fe1b4430ec 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> @@ -4623,9 +4623,6 @@ Type checkIdInternal(JCTree tree,
>                       Type pt,
>                       Env<AttrContext> env,
>                       ResultInfo resultInfo) {
> -            if (pt.isErroneous()) {
> -                return types.createErrorType(site);
> -            }
>              Type owntype; // The computed type of this identifier occurrence.
>              switch (sym.kind) {
>              case TYP:
> @@ -4734,6 +4731,10 @@ else if (ownOuter.hasTag(CLASS) && site != ownOuter) {
>                  chk.checkPreview(tree.pos(), env.info.scope.owner, sym);
>              }
>  
> +            if (pt.isErroneous()) {
> +                owntype = types.createErrorType(owntype);
> +            }
> +
>              // If symbol is a variable, check that its type and
>              // kind are compatible with the prototype and protokind.
>              return check(tree, owntype, sym.kind.toSelector(), resultInfo);
> 
> 
> I.e., let the `checkIdInternal` run as normally, just wrap the type with an error type. When I ran tests with this change, three failed for me:
> 
> FAILED: tools/javac/generics/diamond/7188968/T7188968.java
> FAILED: tools/javac/lambda/methodReference/MethodRefToInnerWithoutOuter.java
> FAILED: tools/javac/lambda/MethodReference23.java
> 
> 
> For the `tools/javac/lambda` tests, the new errors seemed better/more appropriate than the original ones, so those are not a problem I think (but an independent check would be good).
> 
> The `tools/javac/generics/diamond/7188968/T7188968.java` is producing more unchecked warnings with that change, and I am not quite sure if that's appropriate.
> 
> As for a test - test inside JShell is good, but there should be a test inside somewhere `tools/javac`. A good place might be `test/langtools/tools/javac/recovery/AttrRecovery.java`:
> 
>     @Test
>     public void testErroneousTarget() throws Exception {
>         String code = """
>                       public class C {
>                  ...

Thanks for the comment @lahodaj.

Not bailing out so early makes sense I guess. I also looked into the new warnings of `T7188968` with your suggested changes. Adding a `Object unknown = null;` to make the code compile will cause the same warnings, so if they make sense with compiling code, I assume they also make sense with broken code.

Let me know if you want to go forward with your suggestion then. I will, however, most likely only find time to do the changes next week.

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

PR Comment: https://git.openjdk.org/jdk/pull/18383#issuecomment-2116916391

From jlahoda at openjdk.org  Fri May 17 12:21:03 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 17 May 2024 12:21:03 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v2]
In-Reply-To: <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
Message-ID: <rPP9dFn1cJdQRBpTb3Tcf_3Wy2CJS_1sUc5q7rr0-SA=.a291acac-d738-4238-a3c6-4cf497dcbc27@github.com>

On Thu, 28 Mar 2024 08:37:00 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Pasting  e.g.
>> 
>> I m(I i, int x) {
>>    return switch (x) {
>>         default -> i;
>>    };
>> }
>> 
>> in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch.
>> 
>> Javac will not crash but swallow the exception, and create a file containing the command line options.
>> 
>> I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally.
>
> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash
>  - add bug id
>  - Fix jshell crash on unknown type in switch yield

We've discussed with @mcimadamore offline, and changing the output for `T7188968` based on the change I've suggested yesterday is probably OK. I am pretty sure the output for the other two tests is better (more correct) with the suggested change. So, if possible, I would suggest to go with the that change, adjusting the tests.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/18383#issuecomment-2117475781

From hgreule at openjdk.org  Mon May 20 14:56:25 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 20 May 2024 14:56:25 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v3]
In-Reply-To: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
Message-ID: <ll_LqlK8nhk2dU2jyhdTlQLy1BOF8rT5ShCi69Szli4=.29496da7-36e6-48bd-a18c-305ae90edf29@github.com>

> Pasting  e.g.
> 
> I m(I i, int x) {
>    return switch (x) {
>         default -> i;
>    };
> }
> 
> in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch.
> 
> Javac will not crash but swallow the exception, and create a file containing the command line options.
> 
> I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally.

Hannes Greule 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 seven additional commits since the last revision:

 - add testcase
 - Don't bail out early on erroneous type, adjust tests
 - Merge branch 'master' into fix/switch-yield-unknown-type-crash
 - Merge branch 'master' into fix/switch-yield-unknown-type-crash
 - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash
 - add bug id
 - Fix jshell crash on unknown type in switch yield

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18383/files
  - new: https://git.openjdk.org/jdk/pull/18383/files/846ac70c..e3f63b31

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

  Stats: 186428 lines in 3835 files changed: 102926 ins; 63002 del; 20500 mod
  Patch: https://git.openjdk.org/jdk/pull/18383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18383/head:pull/18383

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

From hgreule at openjdk.org  Mon May 20 14:56:28 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Mon, 20 May 2024 14:56:28 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v2]
In-Reply-To: <rPP9dFn1cJdQRBpTb3Tcf_3Wy2CJS_1sUc5q7rr0-SA=.a291acac-d738-4238-a3c6-4cf497dcbc27@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <osLwnT_Wrc9lnzpSTjazDmnDe81RPhlJa0JtWGKhIpo=.a7f59a92-18a3-477a-9ecc-98a1f6082959@github.com>
 <rPP9dFn1cJdQRBpTb3Tcf_3Wy2CJS_1sUc5q7rr0-SA=.a291acac-d738-4238-a3c6-4cf497dcbc27@github.com>
Message-ID: <-frsks4IC5hFbjVwm4hWYr33ycR-1RPgzMTr835nuNw=.09b25eab-925a-4750-8ffe-dee326af5238@github.com>

On Fri, 17 May 2024 12:18:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash
>>  - add bug id
>>  - Fix jshell crash on unknown type in switch yield
>
> We've discussed with @mcimadamore offline, and changing the output for `T7188968` based on the change I've suggested yesterday is probably OK. I am pretty sure the output for the other two tests is better (more correct) with the suggested change. So, if possible, I would suggest to go with the that change, adjusting the tests.
> 
> Thanks!

I adapted your suggested changes and adjusted the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/18383#issuecomment-2120621912

From prappo at openjdk.org  Tue May 21 15:44:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 21 May 2024 15:44:18 GMT
Subject: RFR: 8305457: Implement java.io.IO [v10]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Add diagnostic output
 - Use "expect" that was found
 - Merge branch 'master' into 8305457-Implement-java.io.IO
   
   # Conflicts:
   #	src/java.base/share/classes/java/io/ProxyingConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
   #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
 - Escape prompt
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Clarify input charset
 - Make IO final
 - Fix System.console().readln(null) in jshell
   
   Without it, jshell hangs on me. Will think of a test.
 - Fix typo
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - ... and 10 more: https://git.openjdk.org/jdk/compare/b92bd671...809e98e0

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

Changes: https://git.openjdk.org/jdk/pull/19112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=09
  Stats: 692 lines in 13 files changed: 692 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From aturbanov at openjdk.org  Tue May 21 19:58:05 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 21 May 2024 19:58:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v10]
In-Reply-To: <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>
Message-ID: <d4jnrspQ7DJha26nUJw-aKFQkD0cq8Jj4VJI8LKLC-k=.5c34b3c9-7c4c-4bcf-9223-986c39bafcaa@github.com>

On Tue, 21 May 2024 15:44:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Add diagnostic output
>  - Use "expect" that was found
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - Fix System.console().readln(null) in jshell
>    
>    Without it, jshell hangs on me. Will think of a test.
>  - Fix typo
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b92bd671...809e98e0

src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 78:

> 76:         String line = null;
> 77:         synchronized (writeLock) {
> 78:             synchronized(readLock) {

Suggestion:

            synchronized (readLock) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1608882590

From prappo at openjdk.org  Tue May 21 21:19:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 21 May 2024 21:19:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v10]
In-Reply-To: <d4jnrspQ7DJha26nUJw-aKFQkD0cq8Jj4VJI8LKLC-k=.5c34b3c9-7c4c-4bcf-9223-986c39bafcaa@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>
 <d4jnrspQ7DJha26nUJw-aKFQkD0cq8Jj4VJI8LKLC-k=.5c34b3c9-7c4c-4bcf-9223-986c39bafcaa@github.com>
Message-ID: <W-zrQzJFDXvKseP4RA74LCtJY51UYJDYQaL3DhNKuBo=.46966752-e50a-41a8-9bd5-21eec2f759fb@github.com>

On Tue, 21 May 2024 19:55:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Add diagnostic output
>>  - Use "expect" that was found
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>>  - Escape prompt
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>  - Clarify input charset
>>  - Make IO final
>>  - Fix System.console().readln(null) in jshell
>>    
>>    Without it, jshell hangs on me. Will think of a test.
>>  - Fix typo
>>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/b92bd671...809e98e0
>
> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 78:
> 
>> 76:         String line = null;
>> 77:         synchronized (writeLock) {
>> 78:             synchronized(readLock) {
> 
> Suggestion:
> 
>             synchronized (readLock) {

Sorry, but no. It would be inconsistent with the rest of the file, which for whatever reason (copy-paste?) does not use whitespace between `synchronized` and `(readLock)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1608962852

From aturbanov at openjdk.org  Wed May 22 05:42:04 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 May 2024 05:42:04 GMT
Subject: RFR: 8305457: Implement java.io.IO [v10]
In-Reply-To: <W-zrQzJFDXvKseP4RA74LCtJY51UYJDYQaL3DhNKuBo=.46966752-e50a-41a8-9bd5-21eec2f759fb@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <5di7ye6tSNpauiTtHGwGI7kFG-iWeKpbWGEOXRK88ag=.fcfb14fd-53d3-4c4c-b774-3660cf6495bb@github.com>
 <d4jnrspQ7DJha26nUJw-aKFQkD0cq8Jj4VJI8LKLC-k=.5c34b3c9-7c4c-4bcf-9223-986c39bafcaa@github.com>
 <W-zrQzJFDXvKseP4RA74LCtJY51UYJDYQaL3DhNKuBo=.46966752-e50a-41a8-9bd5-21eec2f759fb@github.com>
Message-ID: <SfOW1jkuRRmH9NhgxOdDKSkUqAHMbHPplVTaY-h4e1s=.0a1897a5-5b19-42a2-82fa-c1ca231da82a@github.com>

On Tue, 21 May 2024 21:16:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 78:
>> 
>>> 76:         String line = null;
>>> 77:         synchronized (writeLock) {
>>> 78:             synchronized(readLock) {
>> 
>> Suggestion:
>> 
>>             synchronized (readLock) {
>
> Sorry, but no. It would be inconsistent with the rest of the file, which for whatever reason (copy-paste?) does not use whitespace between `synchronized` and `(readLock)`.

It looks strange to have space in one case, and don't have it in another. I would'nt call it consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1609287823

From prappo at openjdk.org  Wed May 22 12:45:21 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 May 2024 12:45:21 GMT
Subject: RFR: 8305457: Implement java.io.IO [v11]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <BWldQ320VyWK4nVUSCZIsNx7M_WSpw5LNNMYkBfV4WY=.58c8df02-9bd3-41e6-8ccb-4d0bd15026d7@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

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

  Restructure the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/809e98e0..719560f6

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

  Stats: 177 lines in 1 file changed: 87 ins; 84 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From prappo at openjdk.org  Wed May 22 14:16:41 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 22 May 2024 14:16:41 GMT
Subject: RFR: 8305457: Implement java.io.IO [v12]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <eKVj-jrfX6Lg2hLfJN_gcBSVu5dvAFRpPUBOXQkNIXE=.0e858744-918a-41d5-96d5-0f504817462b@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

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

  Force reasonable terminal size
  
  JLine outputs unexpected stuff if the terminal isn't dumb and small,
  such as that of our CI machines:
  
      if (newLines.size() > displaySize && !isTerminalDumb()) {
          StringBuilder sb = new StringBuilder(">....");
  
  This causes the IO test to fail with timeout, because the expected
  prompt is never matched. To avoid that, we reasonably size the
  terminal.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19112/files
  - new: https://git.openjdk.org/jdk/pull/19112/files/719560f6..e252c5d8

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

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

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

From liach at openjdk.org  Thu May 23 03:33:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 03:33:10 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
Message-ID: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>

Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.

Summary:
1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.

Testing: tier1 and tier2 have no related failures.

Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

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

Commit messages:
 - Fixes
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/hidden-proxy
 - First draft

Changes: https://git.openjdk.org/jdk/pull/19356/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19356&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8242888
  Stats: 303 lines in 8 files changed: 70 ins; 153 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/19356.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19356/head:pull/19356

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

From alanb at openjdk.org  Thu May 23 06:15:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 06:15:00 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <w7DMSgL_VRu-J78a16RHI7SwIvNMwvtBDXsJCBWqkoQ=.94b90b10-7e08-488b-922b-6f831ddfcf2a@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

There are compatibility concerns and behavioural differences that will require significant effort to consider before doing this. This is the reason that this one has been kicked down the road several times.

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126310091

From liach at openjdk.org  Thu May 23 11:28:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 11:28:01 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

A CSR targeting 24 describing the compatibility concerns and behavioral differences is here, somehow not linked by skara: https://bugs.openjdk.org/browse/JDK-8332770
The incompatibilities were much greater in the previous iterations of this issue, such as in dynamic modules, serialization, and in proxy class protection domain. Now these aspects are addressed by this patch, the only real one left is the change in stack trace. Feel free to raise other incompatibilities you have discovered.

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679

From alanb at openjdk.org  Thu May 23 11:39:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 11:39:02 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
Message-ID: <KwnUy2Qkpq1z39wsdBm00ecrCYBk_eYeio248uM1jYc=.eeba80b6-5c26-4d03-85c4-490db6c51a20@github.com>

On Thu, 23 May 2024 11:25:00 GMT, Chen Liang <liach at openjdk.org> wrote:

> A CSR targeting 24 describing the compatibility concerns and behavioral differences is here, somehow not linked by skara: https://bugs.openjdk.org/browse/JDK-8332770 The incompatibilities were much greater in the previous iterations of this issue, such as in dynamic modules, serialization, and in proxy class protection domain. Now these aspects are addressed by this patch, the only real one left is the change in stack trace. Feel free to raise other incompatibilities you have discovered.

Thanks for starting a CSR. The CSR can't be low risk, it's medium at least, maybe high. If we are doing this change then doing it early in a release and putting into outreach to frameworks will be important.

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126890063

From forax at univ-mlv.fr  Thu May 23 11:43:38 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 23 May 2024 13:43:38 +0200 (CEST)
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
Message-ID: <1193071457.29792413.1716464618330.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Chen Liang" <liach at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>, "hotspot-dev" <hotspot-dev at openjdk.org>, kulla-dev at openjdk.org
> Sent: Thursday, May 23, 2024 1:28:01 PM
> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes

> On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:
> 
>> Please review this change that convert dynamic proxies implementations to hidden
>> classes, intended to target JDK 24.
>> 
>> Summary:
>> 1. Adds new implementation while preserving the old implementation behind
>> `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
>> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in
>> native code; I updated native code to reuse that ClassLoader for Proxy support.
>> 3. ProxyGenerator changes mainly involve using Class data to pass Method list
>> (accessed in a single condy) and removal of obsolete setup code generation.
>> 
>> Testing: tier1 and tier2 have no related failures.
>> 
>> Comment: Since #8278, Proxy has been converted to ClassFile API, and
>> infrastructure has changed; now, the migration to hidden classes is much
>> cleaner and has less impact, such as preserving ProtectionDomain and dynamic
>> module without "anchor classes", and avoiding java.lang.invoke package.
> 
> A CSR targeting 24 describing the compatibility concerns and behavioral
> differences is here, somehow not linked by skara:
> https://bugs.openjdk.org/browse/JDK-8332770
> The incompatibilities were much greater in the previous iterations of this
> issue, such as in dynamic modules, serialization, and in proxy class protection
> domain. Now these aspects are addressed by this patch, the only real one left
> is the change in stack trace. Feel free to raise other incompatibilities you
> have discovered.

I wonder if instead of using hidden classes, we should not use usual named classes and add a new Lookup.defineClass() that takes a classData as parameter.
This will solve the both the problem of the stacktrace and the problem of the roundtrip proxyClass != Class.forName(proxyClass.getName()).

R?mi

> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679

From liach at openjdk.org  Thu May 23 13:31:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 13:31:01 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <Q1fAfUu3tYgWGJWQVWYQGFF58eqLCD3N1EyGmpxQ2RI=.e6f90f69-fb25-4584-b7be-1ca4d86c95e4@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

I have updated the compatibility risk description of the CSR.

My CSR proposes to allow dynamic unloading of the proxy implementation classes, but currently it's not implemented as they are strongly referenced in the ClassLoaderValue caches. Should I implement dynamic unloading suggested in the CSR in this patch, or should I do it later?

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2127111543

From forax at univ-mlv.fr  Thu May 23 13:45:14 2024
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 23 May 2024 15:45:14 +0200 (CEST)
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <CABe8uE3mPp1ai8tzNnmXnEk=UJyMsqGjyVdO3MehmPhTo=Da4w@mail.gmail.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <ZlaFVWmLKm_TeaoYNpcIQJqeCMOF807SvUF_NmnVqKw=.5ed04198-6a80-43fd-bdb4-75dc21c9cd9b@github.com>
 <1193071457.29792413.1716464618330.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE3mPp1ai8tzNnmXnEk=UJyMsqGjyVdO3MehmPhTo=Da4w@mail.gmail.com>
Message-ID: <1969145685.29901931.1716471914849.JavaMail.zimbra@univ-eiffel.fr>

> From: "-" <liangchenblue at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Chen Liang" <liach at openjdk.org>, "core-libs-dev"
> <core-libs-dev at openjdk.org>, "hotspot-dev" <hotspot-dev at openjdk.org>,
> "kulla-dev" <kulla-dev at openjdk.org>
> Sent: Thursday, May 23, 2024 2:56:58 PM
> Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes

> Hmm, I think Proxy being hidden in stacktraces might be an advantage; the same
> happens for lambdas.
> The main advantage of hidden classes compared to an explicit class with
> classData is that it supports flexible unloading, which might be useful for
> Proxy.

Flexible unloading has a high cost in term of memory, the class + methods, etc need their own metaspace. 
While on paper it seems great, I've my doubt that it's a good idea to use that option for proxies given that the Proxy API allows an umbounded number of proxy classes. 
That's why lambda proxies does not use the flexible unloading anymore. 

> I still believe the flexible unloading advantage justifies the migration to
> hidden classes.

> Chen

R?mi 

> On Thu, May 23, 2024 at 6:43 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> ----- Original Message -----
>> > From: "Chen Liang" < [ mailto:liach at openjdk.org | liach at openjdk.org ] >
>>> To: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.org |
>>> core-libs-dev at openjdk.org ] >, "hotspot-dev" < [ mailto:hotspot-dev at openjdk.org
>>> | hotspot-dev at openjdk.org ] >, [ mailto:kulla-dev at openjdk.org |
>> > kulla-dev at openjdk.org ]
>> > Sent: Thursday, May 23, 2024 1:28:01 PM
>> > Subject: Re: RFR: 8242888: Convert dynamic proxy to hidden classes

>>> On Thu, 23 May 2024 03:28:30 GMT, Chen Liang < [ mailto:liach at openjdk.org |
>> > liach at openjdk.org ] > wrote:

>> >> Please review this change that convert dynamic proxies implementations to hidden
>> >> classes, intended to target JDK 24.

>> >> Summary:
>> >> 1. Adds new implementation while preserving the old implementation behind
>> >> `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
>> >> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in
>> >> native code; I updated native code to reuse that ClassLoader for Proxy support.
>> >> 3. ProxyGenerator changes mainly involve using Class data to pass Method list
>> >> (accessed in a single condy) and removal of obsolete setup code generation.

>> >> Testing: tier1 and tier2 have no related failures.

>> >> Comment: Since #8278, Proxy has been converted to ClassFile API, and
>> >> infrastructure has changed; now, the migration to hidden classes is much
>> >> cleaner and has less impact, such as preserving ProtectionDomain and dynamic
>> >> module without "anchor classes", and avoiding java.lang.invoke package.

>> > A CSR targeting 24 describing the compatibility concerns and behavioral
>> > differences is here, somehow not linked by skara:
>>> [ https://bugs.openjdk.org/browse/JDK-8332770 |
>> > https://bugs.openjdk.org/browse/JDK-8332770 ]
>> > The incompatibilities were much greater in the previous iterations of this
>> > issue, such as in dynamic modules, serialization, and in proxy class protection
>> > domain. Now these aspects are addressed by this patch, the only real one left
>> > is the change in stack trace. Feel free to raise other incompatibilities you
>> > have discovered.

>> I wonder if instead of using hidden classes, we should not use usual named
>> classes and add a new Lookup.defineClass() that takes a classData as parameter.
>> This will solve the both the problem of the stacktrace and the problem of the
>> roundtrip proxyClass != Class.forName(proxyClass.getName()).

>> R?mi


>> > -------------

>>> PR Comment: [ https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679 |
>> > https://git.openjdk.org/jdk/pull/19356#issuecomment-2126869679 ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20240523/926a8572/attachment-0001.htm>

From alanb at openjdk.org  Thu May 23 14:00:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 May 2024 14:00:12 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <Q1fAfUu3tYgWGJWQVWYQGFF58eqLCD3N1EyGmpxQ2RI=.e6f90f69-fb25-4584-b7be-1ca4d86c95e4@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <Q1fAfUu3tYgWGJWQVWYQGFF58eqLCD3N1EyGmpxQ2RI=.e6f90f69-fb25-4584-b7be-1ca4d86c95e4@github.com>
Message-ID: <TxFTNGUZ2IWWumS8piKQoVRdGn-WdThNJ0N9gOt6joo=.df92f06f-93ce-4852-8769-7923d7ea3949@github.com>

On Thu, 23 May 2024 13:28:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> I have updated the compatibility risk description of the CSR.
> 
> My CSR proposes to allow dynamic unloading of the proxy implementation classes, but currently it's not implemented as they are strongly referenced in the ClassLoaderValue caches. Should I implement dynamic unloading suggested in the CSR in this patch, or should I do it later?

I think the main compatibility concern is going to be that hidden classes don't have a binary name so we have to get a sense as to whether there are frameworks that do anything with the class name and Class.forName.

I suspect the work will also mean looking at cases where agents are somehow instrumenting proxy class (hidden classes are not modifiable). In the JDK 8 time frame we had to back out a change in this area due to one of the mocking tools filtering by class name and trying to redefine proxy classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2127188839

From jlahoda at openjdk.org  Thu May 23 15:59:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 23 May 2024 15:59:15 GMT
Subject: RFR: 8332230: jshell throws AssertionError when processing annotations
Message-ID: <i8P5HyhnNHo8Spg6Z-ZJBPL4h1Ska60vbr-KoU3E4JI=.8fca8fcc-6e67-4897-a618-7b94aa85d8ba@github.com>

Passing snippet `k=aa:a. at a` to JShell crashes it:

jshell> k=aa:a. at a
...
Caused by: java.lang.AssertionError
        at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
        at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
        at jdk.compiler/com.sun.tools.javac.comp.Annotate.fromAnnotations(Annotate.java:167)
        at jdk.compiler/com.sun.tools.javac.comp.Annotate.lambda$annotateTypeSecondStage$5(Annotate.java:1059)
        at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:194)
        at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)


There are two places where relevant work for type annotations is scheduled:
- Attr.visitMethodDef will schedule and perform first stage of type annotation processing before processing the method's body: https://github.com/openjdk/jdk/blob/90758f6735620776fcb60da9e0e2c91a4f53aaf1/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1215
- Attr.visitAnnotatedType will schedule the second phase of type annotation processing: https://github.com/openjdk/jdk/blob/90758f6735620776fcb60da9e0e2c91a4f53aaf1/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L5224

There are two problems here:
a) it may happen that `visitAnnotatedType` schedules the second phase for the given type, but noone calls `Annotate.flush()` anymore before javac finishes. `flush` is in `Attr` called at the beginning of processing of classes, methods, many, but not all variables, etc., but if there's none of them in the source after the task has been scheduled, the task will remain in the queue. This has twofold effect: 1) the model for the type is slightly broken (if we ask of the type annotations on the type, we won't get the annotation); 2) since JShell is using `JavacTaskPool`, and reuses javac tasks, the pending type annotation task may remain in the queue, and be invoked when doing reusing the `JavacTask` for unrelated processing. My proposal here is to call `Annotate.flush()` after "top-level" declarations, to make sure all annotation tasks are always finished.

b) `Attr` visits even erroneous subtrees, so annotated types inside erroneous subtrees will have the second stage scheduled; but the first stage of type annotation processing is not looking inside erroneous subtrees, so the first stage is not done for annotated types inside these subtrees. And the second stage then crashes. My proposal is to let the first stage look into erroneous subtrees.

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

Commit messages:
 - 8332230: jshell throws AssertionError when processing annotations

Changes: https://git.openjdk.org/jdk/pull/19371/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332230
  Stats: 197 lines in 5 files changed: 193 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19371/head:pull/19371

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

From prappo at openjdk.org  Thu May 23 17:14:19 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 23 May 2024 17:14:19 GMT
Subject: RFR: 8305457: Implement java.io.IO [v13]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Force reasonable terminal size
   
   JLine outputs unexpected stuff if the terminal isn't dumb and small,
   such as that of our CI machines:
   
       if (newLines.size() > displaySize && !isTerminalDumb()) {
           StringBuilder sb = new StringBuilder(">....");
   
   This causes the IO test to fail with timeout, because the expected
   prompt is never matched. To avoid that, we reasonably size the
   terminal.
 - Restructure the test
 - Add diagnostic output
 - Use "expect" that was found
 - Merge branch 'master' into 8305457-Implement-java.io.IO
   
   # Conflicts:
   #	src/java.base/share/classes/java/io/ProxyingConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
   #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
 - Escape prompt
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Clarify input charset
 - Make IO final
 - ... and 13 more: https://git.openjdk.org/jdk/compare/e19a421c...258ce133

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

Changes: https://git.openjdk.org/jdk/pull/19112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=12
  Stats: 690 lines in 13 files changed: 690 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From smarks at openjdk.org  Thu May 23 18:39:06 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 23 May 2024 18:39:06 GMT
Subject: RFR: 8305457: Implement java.io.IO [v13]
In-Reply-To: <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>
Message-ID: <8LfSUCtJ1kyqUam65aOt7od1_QTBgUpDSIeUgOX2uHU=.80249710-1354-4fab-ab1d-21af1ce56f9f@github.com>

On Thu, 23 May 2024 17:14:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Force reasonable terminal size
>    
>    JLine outputs unexpected stuff if the terminal isn't dumb and small,
>    such as that of our CI machines:
>    
>        if (newLines.size() > displaySize && !isTerminalDumb()) {
>            StringBuilder sb = new StringBuilder(">....");
>    
>    This causes the IO test to fail with timeout, because the expected
>    prompt is never matched. To avoid that, we reasonably size the
>    terminal.
>  - Restructure the test
>  - Add diagnostic output
>  - Use "expect" that was found
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/e19a421c...258ce133

Updates look good.

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

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2074746185

From liach at openjdk.org  Thu May 23 23:27:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 May 2024 23:27:01 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <A6RYDzBBFGsmRdFEmV0P7r9PL55ri7NlgIQ37MsWJH0=.2f8d69ab-cc90-4582-a7ca-a9f5a459acb5@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

Hmm, actually, looking at the specs of the method again, does it imply that Proxy classes are never unloaded once defined in a ClassLoader, as seen in `Proxy::getProxyClass`:

> If a proxy class for the same permutation of interfaces has already been defined by the class loader, then the existing proxy class will be returned

If that's the case, Remi's suggestion on passing classdata to a non-hidden class might be better, and it seems to accomplish that in hotspot isn't too hard too.

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2128186405

From alanb at openjdk.org  Fri May 24 08:05:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 May 2024 08:05:01 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <A6RYDzBBFGsmRdFEmV0P7r9PL55ri7NlgIQ37MsWJH0=.2f8d69ab-cc90-4582-a7ca-a9f5a459acb5@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <A6RYDzBBFGsmRdFEmV0P7r9PL55ri7NlgIQ37MsWJH0=.2f8d69ab-cc90-4582-a7ca-a9f5a459acb5@github.com>
Message-ID: <WO-JpBzTm-uKYRjeXp29Az2K8XAE5otmimcufHw6RMc=.42099601-3dc0-4895-9795-e336a0ab70ef@github.com>

On Thu, 23 May 2024 23:24:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hmm, actually, looking at the specs of the method again, does it imply that Proxy classes are never unloaded once defined in a ClassLoader, as seen in `Proxy::getProxyClass`:

It's not specified, Proxy pre-dates hidden classes although its Proxy did require some changes to specify that it can't be a proxy to a hidden class. Given the getProxyClass is deprecated then it may be better to have it work the same way as it has always done.

If Proxy::newInstanceClass is changed to return an instance of a hidden class then spec changes are needed. Maybe too early to think about that now as there is a lot of analysis work required to do before going near code.

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

PR Comment: https://git.openjdk.org/jdk/pull/19356#issuecomment-2128853043

From jlahoda at openjdk.org  Fri May 24 11:09:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 May 2024 11:09:05 GMT
Subject: RFR: 8305457: Implement java.io.IO [v13]
In-Reply-To: <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <OeX8FjKjxcEY8Xww8oZ31Uxo5odfSLt9msAYKr5AuIA=.40796307-4eab-4266-a3df-5cf4a8d422c8@github.com>
Message-ID: <iyygb7aV0KxQ_eV6LGyyux5gXb1b6LEcF0wcexXRJTY=.4da936e8-d138-4cb4-8c77-a2d4ae90db96@github.com>

On Thu, 23 May 2024 17:14:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Force reasonable terminal size
>    
>    JLine outputs unexpected stuff if the terminal isn't dumb and small,
>    such as that of our CI machines:
>    
>        if (newLines.size() > displaySize && !isTerminalDumb()) {
>            StringBuilder sb = new StringBuilder(">....");
>    
>    This causes the IO test to fail with timeout, because the expected
>    prompt is never matched. To avoid that, we reasonably size the
>    terminal.
>  - Restructure the test
>  - Add diagnostic output
>  - Use "expect" that was found
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>  - Escape prompt
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Clarify input charset
>  - Make IO final
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/e19a421c...258ce133

JShell-related changes look good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2076598544

From prappo at openjdk.org  Fri May 24 11:30:19 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 24 May 2024 11:30:19 GMT
Subject: RFR: 8305457: Implement java.io.IO [v14]
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <XprICGpbitXh1b925_LstR5gouFRFszxOh1-82yjF3E=.c8cfef99-a48e-4c49-9448-7e01648a6a76@github.com>

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Fix test failure
   
   Caused by 4e6d851f3f061b4a9c2b5d2e3fba6a0277ac1f34:
   
       8325324: Implement JEP 477: Implicitly Declared Classes
                and Instance Main Methods (Third Preview)
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Merge remote-tracking branch 'jdk/master' into 8305457-Implement-java.io.IO
 - Merge branch 'master' into 8305457-Implement-java.io.IO
 - Force reasonable terminal size
   
   JLine outputs unexpected stuff if the terminal isn't dumb and small,
   such as that of our CI machines:
   
       if (newLines.size() > displaySize && !isTerminalDumb()) {
           StringBuilder sb = new StringBuilder(">....");
   
   This causes the IO test to fail with timeout, because the expected
   prompt is never matched. To avoid that, we reasonably size the
   terminal.
 - Restructure the test
 - Add diagnostic output
 - Use "expect" that was found
 - Merge branch 'master' into 8305457-Implement-java.io.IO
   
   # Conflicts:
   #	src/java.base/share/classes/java/io/ProxyingConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
   #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
   #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
   #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
 - Escape prompt
 - ... and 16 more: https://git.openjdk.org/jdk/compare/239c1b33...5edf686d

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

Changes: https://git.openjdk.org/jdk/pull/19112/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19112&range=13
  Stats: 696 lines in 15 files changed: 691 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19112/head:pull/19112

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

From jlahoda at openjdk.org  Fri May 24 13:40:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 24 May 2024 13:40:16 GMT
Subject: RFR: 8305457: Implement java.io.IO [v14]
In-Reply-To: <XprICGpbitXh1b925_LstR5gouFRFszxOh1-82yjF3E=.c8cfef99-a48e-4c49-9448-7e01648a6a76@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
 <XprICGpbitXh1b925_LstR5gouFRFszxOh1-82yjF3E=.c8cfef99-a48e-4c49-9448-7e01648a6a76@github.com>
Message-ID: <khds7PK5-LZONmxHFttV_PrfAG2pxHfPq5R33jHcv2k=.a80637e1-a240-43bc-b16b-2b70c4680ece@github.com>

On Fri, 24 May 2024 11:30:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
>> 
>> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
>> 
>> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
>> [draft PR]: https://github.com/openjdk/jdk/pull/18921
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Fix test failure
>    
>    Caused by 4e6d851f3f061b4a9c2b5d2e3fba6a0277ac1f34:
>    
>        8325324: Implement JEP 477: Implicitly Declared Classes
>                 and Instance Main Methods (Third Preview)
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Merge remote-tracking branch 'jdk/master' into 8305457-Implement-java.io.IO
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>  - Force reasonable terminal size
>    
>    JLine outputs unexpected stuff if the terminal isn't dumb and small,
>    such as that of our CI machines:
>    
>        if (newLines.size() > displaySize && !isTerminalDumb()) {
>            StringBuilder sb = new StringBuilder(">....");
>    
>    This causes the IO test to fail with timeout, because the expected
>    prompt is never matched. To avoid that, we reasonably size the
>    terminal.
>  - Restructure the test
>  - Add diagnostic output
>  - Use "expect" that was found
>  - Merge branch 'master' into 8305457-Implement-java.io.IO
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/io/ProxyingConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsole.java
>    #	src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java
>    #	src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java
>    #	src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
>  - Escape prompt
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/239c1b33...5edf686d

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19112#pullrequestreview-2076957513

From prappo at openjdk.org  Fri May 24 13:40:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 24 May 2024 13:40:18 GMT
Subject: Integrated: 8305457: Implement java.io.IO
In-Reply-To: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
References: <w2msiw_qaMEIJS3s9D4bg8pFbz5WIF0KdP6Mm-XFjLI=.85b2020b-8c46-4bac-8a69-4975b068f2ff@github.com>
Message-ID: <cw8_7M9ZZWTVorsWaj4C3EZmFOwhrFCO5dH7PhnzaXA=.2e4ff058-02ea-4b98-96e8-083b609a5484@github.com>

On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR which introduces the `java.io.IO` top-level class and three methods to `java.io.Console` for [Implicitly Declared Classes and Instance Main Methods (Third Preview)].
> 
> This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
> 
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]: https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921

This pull request has now been integrated.

Changeset: c099f14f
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c099f14f07260713229cffbe7d23aa8305415a67
Stats:     696 lines in 15 files changed: 691 ins; 1 del; 4 mod

8305457: Implement java.io.IO

Reviewed-by: naoto, smarks, jpai, jlahoda

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

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

From duke at openjdk.org  Mon May 27 00:12:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 27 May 2024 00:12:04 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
Message-ID: <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>

On Thu, 23 May 2024 03:28:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
> 
> Summary:
> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
> 
> Testing: tier1 and tier2 have no related failures.
> 
> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.

`useLegacyProxyImpl &&?!useOldSerializableConstructor` would?always be?`false` when `useOldSerializableConstructor` is?`true`, which?is?the?opposite of?what?s?described in?the?CSR.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 557:

> 555:     public static boolean useLegacyProxyImpl() {
> 556:         var config = config();
> 557:         return config.useLegacyProxyImpl && !config.useOldSerializableConstructor;

Suggestion:

        return config.useLegacyProxyImpl || config.useOldSerializableConstructor;

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 624:

> 622:             "true".equals(props.getProperty("jdk.disableSerialConstructorChecks"));
> 623: 
> 624:         useLegacyProxyImpl &= !useOldSerializableConstructor;

Suggestion:

        useLegacyProxyImpl |= useOldSerializableConstructor;

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

PR Review: https://git.openjdk.org/jdk/pull/19356#pullrequestreview-2079825251
PR Review Comment: https://git.openjdk.org/jdk/pull/19356#discussion_r1615362157
PR Review Comment: https://git.openjdk.org/jdk/pull/19356#discussion_r1615362271

From liach at openjdk.org  Mon May 27 01:25:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 27 May 2024 01:25:11 GMT
Subject: RFR: 8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>
References: <QO0dIumbbHUFWz43pCWbmsqdH5zG8NaVUB9FwNFlbTw=.8fe20db2-9cfc-46e9-9f98-0979259ac882@github.com>
 <frmKNM6V-m2MNi9ZHirgqfLgzKRbfVGc73GMj-l-KYU=.2a9e5223-9b85-499b-b391-f9ba89fd73fe@github.com>
Message-ID: <7Kf2Il9AOTNK5iJrHGm0ta37FjRE-1MpVHgv14NA8x0=.0440b81c-607b-4df6-a725-6de09b31b30a@github.com>

On Mon, 27 May 2024 00:03:41 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Please review this change that convert dynamic proxies implementations to hidden classes, intended to target JDK 24.
>> 
>> Summary:
>> 1. Adds new implementation while preserving the old implementation behind `-Djdk.reflect.useLegacyProxyImpl=true` in case there are compatibility issues.
>> 2. ClassLoader.defineClass0 takes a ClassLoader instance but discards it in native code; I updated native code to reuse that ClassLoader for Proxy support.
>> 3. ProxyGenerator changes mainly involve using Class data to pass Method list (accessed in a single condy) and removal of obsolete setup code generation.
>> 
>> Testing: tier1 and tier2 have no related failures.
>> 
>> Comment: Since #8278, Proxy has been converted to ClassFile API, and infrastructure has changed; now, the migration to hidden classes is much cleaner and has less impact, such as preserving ProtectionDomain and dynamic module without "anchor classes", and avoiding java.lang.invoke package.
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 557:
> 
>> 555:     public static boolean useLegacyProxyImpl() {
>> 556:         var config = config();
>> 557:         return config.useLegacyProxyImpl && !config.useOldSerializableConstructor;
> 
> Suggestion:
> 
>         return config.useLegacyProxyImpl || config.useOldSerializableConstructor;

This site can actually simply be `config.useLegacyProxyImpl` as it's initialized in `loadConfig`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19356#discussion_r1615382817

From jlahoda at openjdk.org  Tue May 28 09:13:24 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 28 May 2024 09:13:24 GMT
Subject: RFR: 8332065: Calling readLine(null...) or readPassword(null...) on
 System.console() hangs jshell
Message-ID: <U1ew0iAFDZeoucAg2S9xZzGNXMP9tKVV-NZSCtJ7q7Q=.20a1b22a-e0c2-4103-8b0b-614b5f41da2b@github.com>

JShell supports using `System.console()` when running snippets in a separate VM (the agent). This works by re-sending requests from the agent to the main process.

For some `Console` methods, like `readLine`, this has two phases - first a prompt is sent, and then input is received. But, there's a mistake on the way this is handled: the protocol starts a "transaction", and then goes to process the prompt. And if the prompt processing fails, the "transaction" never ends, and the communication locks.

The proposal here is to do the prompt processing before starting the communication, so if it fails, there are no problems with the communication.

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

Commit messages:
 - Improving tests and implementation.
 - 8332065: Calling readLine(null...) or readPassword(null...) on System.console() hangs jshell

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

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

From prappo at openjdk.org  Tue May 28 11:13:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 May 2024 11:13:04 GMT
Subject: RFR: 8332065: Calling readLine(null...) or readPassword(null...)
 on System.console() hangs jshell
In-Reply-To: <U1ew0iAFDZeoucAg2S9xZzGNXMP9tKVV-NZSCtJ7q7Q=.20a1b22a-e0c2-4103-8b0b-614b5f41da2b@github.com>
References: <U1ew0iAFDZeoucAg2S9xZzGNXMP9tKVV-NZSCtJ7q7Q=.20a1b22a-e0c2-4103-8b0b-614b5f41da2b@github.com>
Message-ID: <cBMDbeMpp-DdxN3abzeUDo1z4wtZUZ-If23YeHHEpXk=.04132ed4-e9d7-45bc-884b-1d0d79117742@github.com>

On Tue, 28 May 2024 09:08:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell supports using `System.console()` when running snippets in a separate VM (the agent). This works by re-sending requests from the agent to the main process.
> 
> For some `Console` methods, like `readLine`, this has two phases - first a prompt is sent, and then input is received. But, there's a mistake on the way this is handled: the protocol starts a "transaction", and then goes to process the prompt. And if the prompt processing fails, the "transaction" never ends, and the communication locks.
> 
> The proposal here is to do the prompt processing before starting the communication, so if it fails, there are no problems with the communication.

Marked as reviewed by prappo (Reviewer).

test/langtools/jdk/jshell/ConsoleTest.java line 194:

> 192:         assertEval("System.console().readPassword(null)", DiagCheck.DIAG_OK, DiagCheck.DIAG_OK, chain(added(Status.VALID), null, EvalException.class));
> 193:         assertEval("System.console().readLine(\"%d\", \"\")", DiagCheck.DIAG_OK, DiagCheck.DIAG_OK, chain(added(Status.VALID), null, EvalException.class));
> 194:         assertEval("System.console().readPassword(\"%d\", \"\")", DiagCheck.DIAG_OK, DiagCheck.DIAG_OK, chain(added(Status.VALID), null, EvalException.class));

Right: `IllegalFormatConversionException` would cause the same hang.

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

PR Review: https://git.openjdk.org/jdk/pull/19420#pullrequestreview-2082461840
PR Review Comment: https://git.openjdk.org/jdk/pull/19420#discussion_r1617036747

From asotona at openjdk.org  Tue May 28 12:13:02 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 28 May 2024 12:13:02 GMT
Subject: RFR: 8332230: jshell throws AssertionError when processing
 annotations
In-Reply-To: <i8P5HyhnNHo8Spg6Z-ZJBPL4h1Ska60vbr-KoU3E4JI=.8fca8fcc-6e67-4897-a618-7b94aa85d8ba@github.com>
References: <i8P5HyhnNHo8Spg6Z-ZJBPL4h1Ska60vbr-KoU3E4JI=.8fca8fcc-6e67-4897-a618-7b94aa85d8ba@github.com>
Message-ID: <x9riXSDw5Ky2Krobl_wzqsS2VFGt2AGK91XvmuO-QmM=.d1d3954e-0669-49c0-9830-9e6aa38b3be0@github.com>

On Thu, 23 May 2024 15:55:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Passing snippet `k=aa:a. at a` to JShell crashes it:
> 
> jshell> k=aa:a. at a
> ...
> Caused by: java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.fromAnnotations(Annotate.java:167)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.lambda$annotateTypeSecondStage$5(Annotate.java:1059)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:194)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
> 
> 
> There are two places where relevant work for type annotations is scheduled:
> - Attr.visitMethodDef will schedule and perform first stage of type annotation processing before processing the method's body: https://github.com/openjdk/jdk/blob/90758f6735620776fcb60da9e0e2c91a4f53aaf1/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1215
> - Attr.visitAnnotatedType will schedule the second phase of type annotation processing: https://github.com/openjdk/jdk/blob/90758f6735620776fcb60da9e0e2c91a4f53aaf1/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L5224
> 
> There are two problems here:
> a) it may happen that `visitAnnotatedType` schedules the second phase for the given type, but noone calls `Annotate.flush()` anymore before javac finishes. `flush` is in `Attr` called at the beginning of processing of classes, methods, many, but not all variables, etc., but if there's none of them in the source after the task has been scheduled, the task will remain in the queue. This has twofold effect: 1) the model for the type is slightly broken (if we ask of the type annotations on the type, we won't get the annotation); 2) since JShell is using `JavacTaskPool`, and reuses javac tasks, the pending type annotation task may remain in the queue, and be invoked when doing reusing the `JavacTask` for unrelated processing. My proposal here is to call `Annotate.flush()` after "top-level" declarations, to make sure all annotation tasks are always finished.
> 
> b) `Attr` visits even erroneous subtrees, so annotated types inside erroneous subtrees will have the second stage scheduled; but the first stage of type annotation processing is not looking inside erroneous subtrees, so the first stage is not done for annotated types inside these subtrees. And the second stage then crashes. My proposal is to let the first...

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19371#pullrequestreview-2082608446

From acobbs at openjdk.org  Thu May 30 01:00:05 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 30 May 2024 01:00:05 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <WgCv9r7PU6F8AVsV6L11tDQJgxMQUu4RQYBFcxPdCog=.64a6eaf2-d643-4a19-aebe-dfa39dc8a737@github.com>

On Tue, 14 May 2024 02:00:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

@lahodaj (or anyone else) - Any comments on this idea?

Presumably this requires a CSR, but I wanted to get a quick sanity check before proceeding further.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19226#issuecomment-2138480652

From jlahoda at openjdk.org  Thu May 30 06:05:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 30 May 2024 06:05:06 GMT
Subject: Integrated: 8332065: Calling readLine(null...) or
 readPassword(null...) on System.console() hangs jshell
In-Reply-To: <U1ew0iAFDZeoucAg2S9xZzGNXMP9tKVV-NZSCtJ7q7Q=.20a1b22a-e0c2-4103-8b0b-614b5f41da2b@github.com>
References: <U1ew0iAFDZeoucAg2S9xZzGNXMP9tKVV-NZSCtJ7q7Q=.20a1b22a-e0c2-4103-8b0b-614b5f41da2b@github.com>
Message-ID: <IxaRvMsaMGEKz6A46BnBWCJ-B85Hc6LU_bzfzjvokxo=.ea11fa9f-70a7-4a23-bbdd-62bc9afc6f07@github.com>

On Tue, 28 May 2024 09:08:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell supports using `System.console()` when running snippets in a separate VM (the agent). This works by re-sending requests from the agent to the main process.
> 
> For some `Console` methods, like `readLine`, this has two phases - first a prompt is sent, and then input is received. But, there's a mistake on the way this is handled: the protocol starts a "transaction", and then goes to process the prompt. And if the prompt processing fails, the "transaction" never ends, and the communication locks.
> 
> The proposal here is to do the prompt processing before starting the communication, so if it fails, there are no problems with the communication.

This pull request has now been integrated.

Changeset: 57bfd0e3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57bfd0e393c58b01cb427a6fbee8ea541ae30efb
Stats:     30 lines in 2 files changed: 24 ins; 5 del; 1 mod

8332065: Calling readLine(null...) or readPassword(null...) on System.console() hangs jshell

Reviewed-by: prappo

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

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

From jlahoda at openjdk.org  Thu May 30 06:05:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 30 May 2024 06:05:15 GMT
Subject: Integrated: 8332230: jshell throws AssertionError when processing
 annotations
In-Reply-To: <i8P5HyhnNHo8Spg6Z-ZJBPL4h1Ska60vbr-KoU3E4JI=.8fca8fcc-6e67-4897-a618-7b94aa85d8ba@github.com>
References: <i8P5HyhnNHo8Spg6Z-ZJBPL4h1Ska60vbr-KoU3E4JI=.8fca8fcc-6e67-4897-a618-7b94aa85d8ba@github.com>
Message-ID: <Dq2R6F5l1Kgdt62szmZhpNIFfImA1J3ctZuWQwZh2IE=.e8bfd064-60f0-4330-85ca-94898f6bc9ec@github.com>

On Thu, 23 May 2024 15:55:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Passing snippet `k=aa:a. at a` to JShell crashes it:
> 
> jshell> k=aa:a. at a
> ...
> Caused by: java.lang.AssertionError
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
>         at jdk.compiler/com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.fromAnnotations(Annotate.java:167)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.lambda$annotateTypeSecondStage$5(Annotate.java:1059)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:194)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
> 
> 
> There are two places where relevant work for type annotations is scheduled:
> - Attr.visitMethodDef will schedule and perform first stage of type annotation processing before processing the method's body: https://github.com/openjdk/jdk/blob/90758f6735620776fcb60da9e0e2c91a4f53aaf1/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1215
> - Attr.visitAnnotatedType will schedule the second phase of type annotation processing: https://github.com/openjdk/jdk/blob/90758f6735620776fcb60da9e0e2c91a4f53aaf1/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L5224
> 
> There are two problems here:
> a) it may happen that `visitAnnotatedType` schedules the second phase for the given type, but noone calls `Annotate.flush()` anymore before javac finishes. `flush` is in `Attr` called at the beginning of processing of classes, methods, many, but not all variables, etc., but if there's none of them in the source after the task has been scheduled, the task will remain in the queue. This has twofold effect: 1) the model for the type is slightly broken (if we ask of the type annotations on the type, we won't get the annotation); 2) since JShell is using `JavacTaskPool`, and reuses javac tasks, the pending type annotation task may remain in the queue, and be invoked when doing reusing the `JavacTask` for unrelated processing. My proposal here is to call `Annotate.flush()` after "top-level" declarations, to make sure all annotation tasks are always finished.
> 
> b) `Attr` visits even erroneous subtrees, so annotated types inside erroneous subtrees will have the second stage scheduled; but the first stage of type annotation processing is not looking inside erroneous subtrees, so the first stage is not done for annotated types inside these subtrees. And the second stage then crashes. My proposal is to let the first...

This pull request has now been integrated.

Changeset: 9a72068e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a72068ef049886dada09e156118b1e9e8f80d11
Stats:     197 lines in 5 files changed: 193 ins; 0 del; 4 mod

8332230: jshell throws AssertionError when processing annotations

Reviewed-by: asotona

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

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

From jlahoda at openjdk.org  Thu May 30 13:55:14 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 30 May 2024 13:55:14 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to JLine
 initalization
Message-ID: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>

Consider these two programs:


public class SystemPrint {
    public static void main(String... args) {
        System.err.println("Hello!");
    }
}

and:

public class IOPrint {
    public static void main(String... args) {
        java.io.IO.println("Hello!");
    }
}


They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.

The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.

For example, on my computer:

$ time java -classpath /tmp SystemPrint 
Hello!

real    0m0,035s
user    0m0,019s
sys     0m0,019s

$ time java -classpath /tmp --enable-preview IOPrint 
Hello!

real    0m0,165s
user    0m0,324s
sys     0m0,042s


The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.

With this patch, I can get timing like this:

$ time java --enable-preview -classpath /tmp/ IOPrint 
Hello!

real    0m0,051s
user    0m0,038s
sys     0m0,020s


which seems much more acceptable.

There is also #19467, which may reduce the time further.

A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

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

Commit messages:
 - Cleanup, addint test.
 - Using println correctly, flushing the java.base delegate before switching to JLine.
 - Force Terminal when writer is requested.
 - Attempting to speedup start by delaying initialization of JLine until really necessary.

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

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

From jlahoda at openjdk.org  Fri May 31 06:19:01 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 31 May 2024 06:19:01 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <rt4-hFhNIRLJQsUIqBnmUGA38TFNnJsSuFidVrVxATc=.b038c1e5-75ec-4ccb-8dc6-e7fc2cbc784a@github.com>

On Tue, 14 May 2024 02:00:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

Sorry for belated reply. This makes sense to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/19226#issuecomment-2141303262

From acobbs at openjdk.org  Fri May 31 18:28:03 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 31 May 2024 18:28:03 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <7QlKEJQlv9uuG4kwPMXFVn9HcjlhCE9NOj5BH5K36A4=.bdb53aec-d22e-40d8-bbe6-e940da811eb3@github.com>

On Tue, 14 May 2024 02:00:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

Awesome, thanks. I'll work on a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19226#issuecomment-2142777364