From jlahoda at openjdk.org  Thu May  1 07:45:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 07:45:55 GMT
Subject: Integrated: 8344708: Implement JEP 511: Module Import Declarations
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <gYaNiDs5PL4NDmpOy9etPHh86GsmJWu_Z_QkubL-OXI=.998a58dc-7470-4204-8f89-23bba1191d55@github.com>

On Wed, 26 Feb 2025 13:50:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a patch to finalize the module imports feature. Please see:
> https://bugs.openjdk.org/browse/JDK-8344700

This pull request has now been integrated.

Changeset: 0a697f6f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a697f6ff4c2f8254e95519e04708cf406009dc3
Stats:     484 lines in 32 files changed: 268 ins; 136 del; 80 mod

8344708: Implement JEP 511: Module Import Declarations

Reviewed-by: mcimadamore, vromero, alanb

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

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

From duke at openjdk.org  Thu May  1 08:47:47 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 1 May 2025 08:47:47 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell
In-Reply-To: <L441y-g1M42ikHks8hnSqpUjlHC9_E6iBU8hWp51sxM=.e0c655b3-15c6-4299-a38f-20e4d4a85824@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <L441y-g1M42ikHks8hnSqpUjlHC9_E6iBU8hWp51sxM=.e0c655b3-15c6-4299-a38f-20e4d4a85824@github.com>
Message-ID: <Z4C6Mq8yMaOU0kAluEzYBIBuXEbLa3SC1lJSe2inhY4=.3c1ff326-2ae7-41a1-a99b-c848d06f09fe@github.com>

On Sat, 26 Apr 2025 18:42:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR will fix not only JDK-8355371 but also JDK-8354910. I chose the more serious one.
>> 
>> Note: according to JEP-512 (JDK-8344699), java.io.IO is going to stop using System.console().
>> I confirmed it by checking out and building https://github.com/openjdk/jdk/pull/24438. (in that PR, the bug does not occur in `IO.print(ln)`)
>> 
>> Before (Temurin 24):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>> |  State engine terminated.     at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> 
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore
>>         at java.base/java.io.OutputStream.write(OutputStream.java:124)
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> |  State engine terminated.
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore   at java.base/java.io.OutputStream.write(OutputStream.java:124)
>> 
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> After (master & without https://github.com/openjdk/jdk/pull/24438):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> I don't know how to prepare the template other PRs use or whether outsiders like me may create a PR.
>
> Newcomer notes:
> 
> 1. Please check this part of the guide https://openjdk.org/guide/#sign-the-oca or the [bot comment](https://github.com/openjdk/jdk/pull/24897#issuecomment-2832348458) for signing the contributor agreement. The robot will automatically update the oca status once you have signed and typed `/signed` command in a github comment.
> 2. Please check our guide https://openjdk.org/guide for more details (though they are too long and many don't apply to newcomers); for example, these files need license header updates. See https://openjdk.org/guide/#making-a-change. 
> 3. Our bot has a lot of commands. See https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands for details. For example, we have [`/issue`](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/issue) to add other issues fixed by the same PR; you can use that to include the other issue you want.

@liach Could you review the latest commit again? Sorry for bothering you.

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

PR Comment: https://git.openjdk.org/jdk/pull/24897#issuecomment-2844394829

From duke at openjdk.org  Thu May  1 09:55:49 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 1 May 2025 09:55:49 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
Message-ID: <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>

On Sun, 27 Apr 2025 14:23:50 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> I misunderstood that I have tested `stdin.encoding`.
>> I cannot confirm that `stdin.encoding` is changed in Windows to proper ones because it has not been included in the latest EA build (20) and I cannot build master for Windows. However, it is changed to `US-ASCII` in Ubuntu when I change `LANG`. I will believe its author until the latest EA build is updated.
>
> Anyway you need to merge master first to test `stdin.encoding`.

`stdin.encoding` seems to work as intended in Windows for Japanese. No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070108439

From liach at openjdk.org  Thu May  1 14:21:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 14:21:46 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell [v2]
In-Reply-To: <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
Message-ID: <NU9pwSEAZ6VPXvRsWayXEBYUlTEFaCdgNgEJnt1wQ0Y=.93313f3e-013c-4b68-9d69-b980b5fb549a@github.com>

On Wed, 30 Apr 2025 23:22:16 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> This PR will fix not only JDK-8355371 but also JDK-8354910. I chose the more serious one.
>> 
>> Note: according to JEP-512 (JDK-8344699), java.io.IO is going to stop using System.console().
>> I confirmed it by checking out and building https://github.com/openjdk/jdk/pull/24438. (in that PR, the bug does not occur in `IO.print(ln)`)
>> 
>> Before (Temurin 24):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>> |  State engine terminated.     at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> 
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore
>>         at java.base/java.io.OutputStream.write(OutputStream.java:124)
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> |  State engine terminated.
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore   at java.base/java.io.OutputStream.write(OutputStream.java:124)
>> 
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> After (master & without https://github.com/openjdk/jdk/pull/24438):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> I don't know how to prepare the template other PRs use or whether outsiders like me may create a PR.
>
> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Escape katakana

The char update looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24897#pullrequestreview-2809882455

From smarks at openjdk.org  Thu May  1 16:57:53 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 1 May 2025 16:57:53 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
Message-ID: <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>

On Thu, 1 May 2025 09:51:41 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Anyway you need to merge master first to test `stdin.encoding`.
>
> `stdin.encoding` seems to work as intended in Windows for Japanese. (I managed to get the Windows binary of my PR) No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.

Hello @tats-u , there is no bother, I appreciate you looking at this.

The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.

Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.

In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070508985

From jlahoda at openjdk.org  Thu May  1 17:44:47 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 17:44:47 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v7]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <79mjbgCz8a1HC6r0_an5GwcY6lWssji50XWSoV1lrlM=.5fea494d-0bad-4e73-a482-090f47663302@github.com>

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

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

 - Merge branch 'master' into finalize-concise-source-files
 - Merge branch 'master' into finalize-concise-source-files
 - Merge remote-tracking branch 'origin/finalize-concise-source-files' into finalize-concise-source-files
 - Add clause about handling of malformed/unmappable bytes.
 - Rewrite bits about charset decoding, removing mention of "internal objects."
 - Use local variable for System.out in print().
 - Reverting test commit.
   
   This reverts commit 7047cf007cc7de937aa21e96125083ee92932692.
 - Fixing tests.
 - Updating copyright year.
 - Adding bug number to tests.
 - ... and 28 more: https://git.openjdk.org/jdk/compare/6b553acb...3868019e

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

Changes: https://git.openjdk.org/jdk/pull/24438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=06
  Stats: 1060 lines in 59 files changed: 336 ins; 585 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/24438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24438/head:pull/24438

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

From vromero at openjdk.org  Thu May  1 18:32:00 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 May 2025 18:32:00 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
Message-ID: <m4Ee1G4zMqDSM8ftPnlnPGTAr4_iDT7jOQgGF8F1S34=.789aa973-ef26-41a8-8d3b-d2597f2b874c@github.com>

On Thu, 1 May 2025 17:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year.

last changes lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2810409833

From jlahoda at openjdk.org  Thu May  1 17:48:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 May 2025 17:48:22 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

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

  Updating copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/3868019e..5d0a867f

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

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

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

From liach at openjdk.org  Thu May  1 18:57:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 18:57:50 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
Message-ID: <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>

On Thu, 1 May 2025 17:48:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year.

src/java.base/share/classes/java/lang/IO.java line 157:

> 155:      * <p>
> 156:      * Writes a prompt as if by calling {@code print}, and then reads a single
> 157:      * line of text as if by calling {@link readln readln()}.

Is this intended to render like `readln` or `readln()`? I always recommend prefixing member references with `#` like `#readln()`.

src/java.base/share/classes/java/lang/IO.java line 179:

> 177:      * the reader() method.
> 178:      */
> 179:     static BufferedReader br;

The comments should indicate all access should be through `reader`, and this field is best made private to indicate direct field access is **not thread safe**.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070645283
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070647143

From naoto at openjdk.org  Thu May  1 17:44:48 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 May 2025 17:44:48 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
Message-ID: <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>

On Thu, 1 May 2025 16:55:06 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> `stdin.encoding` seems to work as intended in Windows for Japanese. (I managed to get the Windows binary of my PR) No need to change. (I wish the constructors of `InputStreamReader` and `Scanner` used `stdin.encoding` instead of UTF-8 for `System.in` by defaultI) Sorry to have bothered you.
>
> Hello @tats-u , there is no bother, I appreciate you looking at this.
> 
> The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.
> 
> Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.
> 
> In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.

`InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070569424

From duke at openjdk.org  Thu May  1 23:40:49 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 1 May 2025 23:40:49 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
 <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
Message-ID: <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>

On Thu, 1 May 2025 17:40:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @tats-u , there is no bother, I appreciate you looking at this.
>> 
>> The addition of `stdin.encoding` in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703) (#24738) happened very quickly. I worked with @naotoj and @AlanBateman on it and we think it does the right thing, but there are many Windows configurations that we don't have the opportunity to test, so more feedback is helpful.
>> 
>> Initially it would be good to understand if `stdin.encoding` is specified and implemented correctly, and whether it provides the right behavior for `java.lang.IO` in JEP 512.
>> 
>> In the future we can consider additional uses of `stdin.encoding` in other parts of the JDK.
>
> `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
> As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.

In Java 17 or prior, non-advanced Windows users especially whose language has a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had been satisfied the behavior at that time. 
JEP 400 broke everything in stdin in Windows. Currently we need to check both stdin.encoding and (sun.)stdout.encoding in every constructor caller to support older Java versions. 

One idea to fix is to check whether the parameter InpuReader is System.in or not in the constructor of InputStreamReader.

https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070927346

From duke at openjdk.org  Fri May  2 00:00:59 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Fri, 2 May 2025 00:00:59 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v5]
In-Reply-To: <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <dFfo7XWntOoKDqWbOSksw2xon3geOvm2h7WuLsodIU0=.6480d447-b14b-43ea-a673-f36e7cbed4fa@github.com>
 <R26A-RFOkbja1bnImimPwn63l0Ey3wceWkCsJg1Jox4=.5621fccc-d59e-4a51-88e9-1c28d9ae9b86@github.com>
 <cNouC_Qp5yZHSyxMdZfBkmprp60u0UPlBS8kL9AVhz0=.4d085a45-cb66-4656-8ba2-41944478c989@github.com>
 <GENBQaAlYVOW6PdXkzHSCIgUIEbVMzMj4_s-E7YLD1c=.125d5f41-50bc-4e0c-befc-f2f7da3eb94e@github.com>
 <kyprg1QUTFY-8ena7wHOk6yOXvqTyq--2ixH5iaksr4=.0ab73659-5a4c-4f81-a8d8-9e1c43d04890@github.com>
 <or1dOrcjcz7XlL_vE6DZbAq1NdWPlX565oTa4_4eJcQ=.9f1b9dcf-57a7-4f36-90b8-bdf492a8fe86@github.com>
 <k_WmWojaK6sUQYgs_a_wfnU1hBnTJb23k4avXhPI8pg=.ecc7d452-0ba0-420a-8c11-443d60c76df3@github.com>
 <Rvch_7UMKRSFCsJqbkDZEHYkHwhu9kvNqFb24QVVXBQ=.16c48f94-807e-4b42-9952-e341e24c28c4@github.com>
 <Kjd6TXMbXvhKTTbmK9LHVMTNuy87YxB_alqV4IBww9E=.e550c9ca-8cec-4177-ae57-df45f0d17f0f@github.com>
Message-ID: <dpz22BvUdBRhm09g40hJF6ErZ6YkGsVhe5onequrAE8=.1b58e1c7-342d-4694-99a6-fff46bdda61b@github.com>

On Thu, 1 May 2025 23:33:00 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> `InputStreamReader` and `Scanner` taking `stdin.encoding` is an interesting idea, but would introduce compatiblity concerns. It would have been simpler if we had `stdin/out/err.encoding` system properties prior to JEP 400. 
>> As to testing on Windows, I would like to know how the Windows `UILanguage` affects these, afaik we only have tested on English Windows. Say how it works on Japanese Windows with English system locale. However, since we have not changed any existing behavior (from the code wise), I don't think we would see any issues.
>
> In Java 17 or prior, non-advanced Windows users especially whose language has a common encodings for ANSI/OEM code page (e.g. Windows-31J for Japanese) had been satisfied the behavior at that time. 
> JEP 400 broke everything in stdin in Windows. Currently we need to check both stdin.encoding and (sun.)stdout.encoding in every constructor caller to support older Java versions. 
> 
> One idea to fix is to check whether the parameter InpuReader is System.in or not in the constructor of InputStreamReader.
> 
> https://github.com/tats-u/jdk/commit/3cbc7be971234ed3c52899ef2b16c040dc120418

I think we have only to change console encodings by e.g. `chcp 932` (CMD) or `[Console]::InputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::Get Encoding(932)` (PowerShell) in Windows. They correspond to `GetConsoleCP` and `GetConsoleOutputCP`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070940588

From jlahoda at openjdk.org  Fri May  2 00:57:27 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 00:57:27 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v9]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

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

  Make br field private; tweaks to javadoc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/5d0a867f..9c095792

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

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

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

From liach at openjdk.org  Fri May  2 00:57:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 00:57:27 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v9]
In-Reply-To: <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <EBU-QaOtBooxLw8S407r5r9pkYdpdbqqBomY2P0HSQg=.e1a20ecf-c59f-4e3f-8bdf-b5abb3cf7179@github.com>
Message-ID: <MmlwdH84URKZQSJ58wgMC8x2oa0K0dk-9fL2UVpd0Wg=.2816b649-b2bb-4755-a9e2-ca4d01079017@github.com>

On Fri, 2 May 2025 00:54:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
>> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
>> - `java. ... .IO` is no longer automatically imported in any compilation unit
>> - the feature is finalized (i.e. no longer requires `--enable-preview`)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make br field private; tweaks to javadoc.

Thanks for the update Stuart. Looks all good to me.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24438#pullrequestreview-2810991411

From smarks at openjdk.org  Fri May  2 00:57:28 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 May 2025 00:57:28 GMT
Subject: RFR: 8344706: Implement JEP 512: Compact Source Files and Instance
 Main Methods [v8]
In-Reply-To: <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <1A_LfHnrQAYX8QlmRbWkilB3QccWeyMjSLWUpYQEuto=.b6448876-a863-4e2a-afac-730bfca1aa8b@github.com>
 <i0nrNOxJvTqW1RuRYN6dWWU4-1ArgqLAJ2o9GH7Ks1U=.9e4d7ba6-1126-4621-bd97-23d733261b67@github.com>
Message-ID: <DwFCtgnc0mjxhkH-11NwxxcgJWF7oa4US8167hX8Lv4=.b2af64ee-55c2-43b1-b8a7-37ad05d2a67c@github.com>

On Thu, 1 May 2025 18:43:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating copyright year.
>
> src/java.base/share/classes/java/lang/IO.java line 157:
> 
>> 155:      * <p>
>> 156:      * Writes a prompt as if by calling {@code print}, and then reads a single
>> 157:      * line of text as if by calling {@link readln readln()}.
> 
> Is this intended to render like `readln` or `readln()`? I always recommend prefixing member references with `#` like `#readln()`.

I added `#` prefixes. I had intended `readln()` to indicate that this referred to the no-arg overload of `readln()` but I think that's too subtle so I removed the parens. But one has to look at the link to determine that it refers to the no-arg readln and not the one-arg readln (which is this method). I also changed the `print` to a link as well.

> src/java.base/share/classes/java/lang/IO.java line 179:
> 
>> 177:      * the reader() method.
>> 178:      */
>> 179:     static BufferedReader br;
> 
> The comments should indicate all access should be through `reader`, and this field is best made private to indicate direct field access is **not thread safe**.

Added a comment. Making it `private` doesn't really help, but I made it private anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070971289
PR Review Comment: https://git.openjdk.org/jdk/pull/24438#discussion_r2070970447

From duke at openjdk.org  Fri May  2 03:35:52 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Fri, 2 May 2025 03:35:52 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell
In-Reply-To: <L441y-g1M42ikHks8hnSqpUjlHC9_E6iBU8hWp51sxM=.e0c655b3-15c6-4299-a38f-20e4d4a85824@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <L441y-g1M42ikHks8hnSqpUjlHC9_E6iBU8hWp51sxM=.e0c655b3-15c6-4299-a38f-20e4d4a85824@github.com>
Message-ID: <TGz6hInQjtzUgZRlI1zjmvHv6hzk6w_UhHvoTt_eoeo=.0cc0f1d8-4653-4a71-a608-21f98663acfd@github.com>

On Sat, 26 Apr 2025 18:42:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR will fix not only JDK-8355371 but also JDK-8354910. I chose the more serious one.
>> 
>> Note: according to JEP-512 (JDK-8344699), java.io.IO is going to stop using System.console().
>> I confirmed it by checking out and building https://github.com/openjdk/jdk/pull/24438. (in that PR, the bug does not occur in `IO.print(ln)`)
>> 
>> Before (Temurin 24):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>> |  State engine terminated.     at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> 
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore
>>         at java.base/java.io.OutputStream.write(OutputStream.java:124)
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> |  State engine terminated.
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore   at java.base/java.io.OutputStream.write(OutputStream.java:124)
>> 
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> After (master & without https://github.com/openjdk/jdk/pull/24438):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> I don't know how to prepare the template other PRs use or whether outsiders like me may create a PR.
>
> Newcomer notes:
> 
> 1. Please check this part of the guide https://openjdk.org/guide/#sign-the-oca or the [bot comment](https://github.com/openjdk/jdk/pull/24897#issuecomment-2832348458) for signing the contributor agreement. The robot will automatically update the oca status once you have signed and typed `/signed` command in a github comment.
> 2. Please check our guide https://openjdk.org/guide for more details (though they are too long and many don't apply to newcomers); for example, these files need license header updates. See https://openjdk.org/guide/#making-a-change. 
> 3. Our bot has a lot of commands. See https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands for details. For example, we have [`/issue`](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/issue) to add other issues fixed by the same PR; you can use that to include the other issue you want.

@liach Thank you for your approval. Can I run the integrate command or should I wait until @lahodaj 's 2nd review?

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

PR Comment: https://git.openjdk.org/jdk/pull/24897#issuecomment-2846236168

From liach at openjdk.org  Fri May  2 03:54:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 03:54:51 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell [v2]
In-Reply-To: <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
Message-ID: <qdeKqTxjwchMZ-Di5zHdulbkmgnQIX4imK3fUy0j3rI=.3634fee8-0b75-4bc0-a776-d21731187cd6@github.com>

On Wed, 30 Apr 2025 23:22:16 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> This PR will fix not only JDK-8355371 but also JDK-8354910. I chose the more serious one.
>> 
>> Note: according to JEP-512 (JDK-8344699), java.io.IO is going to stop using System.console().
>> I confirmed it by checking out and building https://github.com/openjdk/jdk/pull/24438. (in that PR, the bug does not occur in `IO.print(ln)`)
>> 
>> Before (Temurin 24):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>> |  State engine terminated.     at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> 
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore
>>         at java.base/java.io.OutputStream.write(OutputStream.java:124)
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> |  State engine terminated.
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore   at java.base/java.io.OutputStream.write(OutputStream.java:124)
>> 
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> After (master & without https://github.com/openjdk/jdk/pull/24438):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> I don't know how to prepare the template other PRs use or whether outsiders like me may create a PR.
>
> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Escape katakana

Let's wait for Jan - I think it is holiday for Jan so you might need to wait for a few days.

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

PR Comment: https://git.openjdk.org/jdk/pull/24897#issuecomment-2846252082

From jlahoda at openjdk.org  Fri May  2 06:12:46 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 06:12:46 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell [v2]
In-Reply-To: <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
Message-ID: <ySmxmzGkGNjW7IJazEtvC2bGSZ6Q2Nv_4IjyHPwkMJc=.55c1ca93-ef67-4b06-bc81-18b91ef8503f@github.com>

On Wed, 30 Apr 2025 23:22:16 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> This PR will fix not only JDK-8355371 but also JDK-8354910. I chose the more serious one.
>> 
>> Note: according to JEP-512 (JDK-8344699), java.io.IO is going to stop using System.console().
>> I confirmed it by checking out and building https://github.com/openjdk/jdk/pull/24438. (in that PR, the bug does not occur in `IO.print(ln)`)
>> 
>> Before (Temurin 24):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>> |  State engine terminated.     at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> 
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore
>>         at java.base/java.io.OutputStream.write(OutputStream.java:124)
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> |  State engine terminated.
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore   at java.base/java.io.OutputStream.write(OutputStream.java:124)
>> 
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> After (master & without https://github.com/openjdk/jdk/pull/24438):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> I don't know how to prepare the template other PRs use or whether outsiders like me may create a PR.
>
> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Escape katakana

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24897#pullrequestreview-2811241537

From jlahoda at openjdk.org  Fri May  2 06:13:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 06:13:57 GMT
Subject: Integrated: 8344706: Implement JEP 512: Compact Source Files and
 Instance Main Methods
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <7qJ1POdMGcRYtfcq6u1v6pcCu3MCfOFXoAZIyOf9IVA=.aeb8b7db-e8bf-4db9-9dcc-fd7f55549c39@github.com>

On Fri, 4 Apr 2025 07:20:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a PR that implements JEP: Compact Source Files and Instance Main Methods. Changes include:
> - `java.io.IO` moved to `java.lang.IO`, and no longer uses `System.console()` to implement the methods (thanks to @stuart-marks)
> - `java. ... .IO` is no longer automatically imported in any compilation unit
> - the feature is finalized (i.e. no longer requires `--enable-preview`)

This pull request has now been integrated.

Changeset: d29700cc
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d29700cc80003d6baddb419f2974ab226478bacc
Stats:     1061 lines in 59 files changed: 336 ins; 585 del; 140 mod

8344706: Implement JEP 512: Compact Source Files and Instance Main Methods

Co-authored-by: Stuart Marks <smarks at openjdk.org>
Reviewed-by: liach, cstein, vromero, naoto

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

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

From duke at openjdk.org  Fri May  2 09:03:47 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Fri, 2 May 2025 09:03:47 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell [v2]
In-Reply-To: <ySmxmzGkGNjW7IJazEtvC2bGSZ6Q2Nv_4IjyHPwkMJc=.55c1ca93-ef67-4b06-bc81-18b91ef8503f@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
 <ySmxmzGkGNjW7IJazEtvC2bGSZ6Q2Nv_4IjyHPwkMJc=.55c1ca93-ef67-4b06-bc81-18b91ef8503f@github.com>
Message-ID: <6RGDcsL7Ly10rG1ZAOW0RKHSBz9fZE9T-gTubrwOfiE=.ac84f117-63b2-4005-9d88-4bc9a3ff5f18@github.com>

On Fri, 2 May 2025 06:10:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Escape katakana
>
> Looks good to me, thanks!

@lahodaj Thank you for your approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/24897#issuecomment-2846709559

From duke at openjdk.org  Fri May  2 09:03:48 2025
From: duke at openjdk.org (duke)
Date: Fri, 2 May 2025 09:03:48 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell [v2]
In-Reply-To: <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
Message-ID: <WEU5LXQEZ2TKq43Q8fHfdRMz19k76hAswoYUPsyZ3bE=.0716b673-0245-42b9-8a71-c087648971c5@github.com>

On Wed, 30 Apr 2025 23:22:16 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> This PR will fix not only JDK-8355371 but also JDK-8354910. I chose the more serious one.
>> 
>> Note: according to JEP-512 (JDK-8344699), java.io.IO is going to stop using System.console().
>> I confirmed it by checking out and building https://github.com/openjdk/jdk/pull/24438. (in that PR, the bug does not occur in `IO.print(ln)`)
>> 
>> Before (Temurin 24):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>> |  State engine terminated.     at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> 
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore
>>         at java.base/java.io.OutputStream.write(OutputStream.java:124)
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> |  State engine terminated.
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore   at java.base/java.io.OutputStream.write(OutputStream.java:124)
>> 
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> After (master & without https://github.com/openjdk/jdk/pull/24438):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> I don't know how to prepare the template other PRs use or whether outsiders like me may create a PR.
>
> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Escape katakana

@tats-u 
Your change (at version 7225a19064170f56c5886c0436b368acacac5729) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24897#issuecomment-2846711342

From duke at openjdk.org  Fri May  2 09:03:48 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Fri, 2 May 2025 09:03:48 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell [v2]
In-Reply-To: <qdeKqTxjwchMZ-Di5zHdulbkmgnQIX4imK3fUy0j3rI=.3634fee8-0b75-4bc0-a776-d21731187cd6@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
 <qdeKqTxjwchMZ-Di5zHdulbkmgnQIX4imK3fUy0j3rI=.3634fee8-0b75-4bc0-a776-d21731187cd6@github.com>
Message-ID: <-lVrAuGOa2sfgumY-UpG_oTHzzKO50aphNYKNyO-zuI=.7e52367e-4d5b-48cb-95ce-24add0cef937@github.com>

On Fri, 2 May 2025 03:52:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Escape katakana
>
> Let's wait for Jan - I think it is holiday for Jan so you might need to wait for a few days.

@liach @lahodaj Thank you in advance for /sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/24897#issuecomment-2846714745

From jlahoda at openjdk.org  Fri May  2 15:06:49 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 15:06:49 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell [v2]
In-Reply-To: <qdeKqTxjwchMZ-Di5zHdulbkmgnQIX4imK3fUy0j3rI=.3634fee8-0b75-4bc0-a776-d21731187cd6@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
 <qdeKqTxjwchMZ-Di5zHdulbkmgnQIX4imK3fUy0j3rI=.3634fee8-0b75-4bc0-a776-d21731187cd6@github.com>
Message-ID: <yCFl-u-SnvgapHQdOTCa3Ns5KXFEITtRKfGUxz077Og=.48127245-8131-456d-9c71-5f517c90e3a9@github.com>

On Fri, 2 May 2025 03:52:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Escape katakana
>
> Let's wait for Jan - I think it is holiday for Jan so you might need to wait for a few days.

FWIW, I have ran tests just to be sure, turned out OK. It is a bit late for me right before the weekend, so I am a bit reluctant to sponsor right now. Unless @liach sponsors before that, I'll sponsor on Monday morning.

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

PR Comment: https://git.openjdk.org/jdk/pull/24897#issuecomment-2847424941

From jlahoda at openjdk.org  Fri May  2 18:15:42 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 18:15:42 GMT
Subject: RFR: 8299934: LocalExecutionControl replaces default uncaught
 exception handler [v2]
In-Reply-To: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
References: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
Message-ID: <3fNMLtOWbI1oN0tFKqTfCnK8vVCiCg8E-mWvZ9f_uQU=.4c91ce1b-761a-4956-82dc-82aa8c957938@github.com>

> The JShell's `LocalExecutionControl` set the global default uncaught exception handler, causing problems to external code that might rely on it (even if only for logging/debugging purposes).
> 
> The proposal here is to do what the bug is suggesting, and only handling the exception inside the `ThreadGroup` that JShell creates. The patch does not strive to do further changes to how the exception handling is done.

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

  Updating copyright years.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12982/files
  - new: https://git.openjdk.org/jdk/pull/12982/files/02bcfea2..7dfb749e

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

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

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

From jlahoda at openjdk.org  Fri May  2 18:29:34 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 2 May 2025 18:29:34 GMT
Subject: RFR: 8299934: LocalExecutionControl replaces default uncaught
 exception handler [v3]
In-Reply-To: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
References: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
Message-ID: <igO28GCVpGaLRrr38fE6y3RNjbHYw2JY0GL5gDkZFaA=.87775771-ba51-462f-8d56-dd7ca1a377a7@github.com>

> The JShell's `LocalExecutionControl` set the global default uncaught exception handler, causing problems to external code that might rely on it (even if only for logging/debugging purposes).
> 
> The proposal here is to do what the bug is suggesting, and only handling the exception inside the `ThreadGroup` that JShell creates. The patch does not strive to do further changes to how the exception handling is done.

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. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8299934
 - Updating copyright years.
 - 8299934: LocalExecutionControl replaces default uncaught exception handler

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12982/files
  - new: https://git.openjdk.org/jdk/pull/12982/files/7dfb749e..a329f2bf

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

  Stats: 3656895 lines in 30744 files changed: 1759207 ins; 1289706 del; 607982 mod
  Patch: https://git.openjdk.org/jdk/pull/12982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12982/head:pull/12982

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

From liach at openjdk.org  Fri May  2 19:02:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 May 2025 19:02:07 GMT
Subject: RFR: 8299934: LocalExecutionControl replaces default uncaught
 exception handler [v3]
In-Reply-To: <igO28GCVpGaLRrr38fE6y3RNjbHYw2JY0GL5gDkZFaA=.87775771-ba51-462f-8d56-dd7ca1a377a7@github.com>
References: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
 <igO28GCVpGaLRrr38fE6y3RNjbHYw2JY0GL5gDkZFaA=.87775771-ba51-462f-8d56-dd7ca1a377a7@github.com>
Message-ID: <sOfdOsnox74a2Mmh7UYKiJ8hIU7Ti8ioYEfr6vlHKDU=.724e31de-1c65-4597-a258-cd229f4b47a0@github.com>

On Fri, 2 May 2025 18:29:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The JShell's `LocalExecutionControl` set the global default uncaught exception handler, causing problems to external code that might rely on it (even if only for logging/debugging purposes).
>> 
>> The proposal here is to do what the bug is suggesting, and only handling the exception inside the `ThreadGroup` that JShell creates. The patch does not strive to do further changes to how the exception handling is done.
>
> 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. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8299934
>  - Updating copyright years.
>  - 8299934: LocalExecutionControl replaces default uncaught exception handler

Copyright year update looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12982#pullrequestreview-2812709456

From duke at openjdk.org  Sat May  3 06:18:47 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sat, 3 May 2025 06:18:47 GMT
Subject: RFR: 8355371: NegativeArraySizeException in print methods in IO or
 System.console() in JShell [v2]
In-Reply-To: <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
 <vf7m5dhYMltIR7evLdjgImO7Fg8xm9SydqmjNitpIzs=.61bea624-60dd-4d7c-a58c-4b043158800b@github.com>
Message-ID: <EQPEEwEeUAWuCQ7MNQ_cAkXbNIuHqhbp7qG0zZd0DeI=.c617283b-fa27-4101-b35c-11d50d911393@github.com>

On Wed, 30 Apr 2025 23:22:16 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> This PR will fix not only JDK-8355371 but also JDK-8354910. I chose the more serious one.
>> 
>> Note: according to JEP-512 (JDK-8344699), java.io.IO is going to stop using System.console().
>> I confirmed it by checking out and building https://github.com/openjdk/jdk/pull/24438. (in that PR, the bug does not occur in `IO.print(ln)`)
>> 
>> Before (Temurin 24):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>> |  State engine terminated.     at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> 
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore
>>         at java.base/java.io.OutputStream.write(OutputStream.java:124)
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
>> |  State engine terminated.
>>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
>> |  Restore definitions with: /reload -restore   at java.base/java.io.OutputStream.write(OutputStream.java:124)
>> 
>>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> After (master & without https://github.com/openjdk/jdk/pull/24438):
>> 
>> 
>> jshell> IO.println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> IO.println("?????")
>> ?????
>> 
>> jshell> System.console().writer().println("a".repeat(128))
>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>> 
>> jshell> System.console().writer().println("?????")
>> ?????
>> 
>> 
>> I don't know how to prepare the template other PRs use or whether outsiders like me may create a PR.
>
> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Escape katakana

I got it. Have a nice weekend.

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

PR Comment: https://git.openjdk.org/jdk/pull/24897#issuecomment-2848459685

From duke at openjdk.org  Mon May  5 05:05:51 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Mon, 5 May 2025 05:05:51 GMT
Subject: Integrated: 8355371: NegativeArraySizeException in print methods in IO
 or System.console() in JShell
In-Reply-To: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
References: <ESo0lOQUEhxWO_m3v5DUQiCFZxSVaN01cpE-DcQjeO4=.6b424d53-55b8-4f03-96b7-c2614d51122f@github.com>
Message-ID: <oaZFgI_XHHTP6mV9_3qwx7buGgim3Dii2TtWUlXv1nk=.0379f62f-aaf6-492b-ba19-4bdd35d1f7ad@github.com>

On Sat, 26 Apr 2025 15:54:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> This PR will fix not only JDK-8355371 but also JDK-8354910. I chose the more serious one.
> 
> Note: according to JEP-512 (JDK-8344699), java.io.IO is going to stop using System.console().
> I confirmed it by checking out and building https://github.com/openjdk/jdk/pull/24438. (in that PR, the bug does not occur in `IO.print(ln)`)
> 
> Before (Temurin 24):
> 
> 
> jshell> IO.println("a".repeat(128))
> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
> |  State engine terminated.     at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
> 
>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
> |  Restore definitions with: /reload -restore
>         at java.base/java.io.OutputStream.write(OutputStream.java:124)
>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
> 
> jshell> IO.println("?????")
> ?????
> 
> jshell> System.console().writer().println("a".repeat(128))
> Exception in thread "output reader" java.lang.NegativeArraySizeException: -128
>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.readCharsOrNull(ConsoleImpl.java:486)
> |  State engine terminated.
>         at jdk.jshell/jdk.jshell.execution.impl.ConsoleImpl$ConsoleOutputStream.write(ConsoleImpl.java:402)
>         at java.base/java.io.OutputStream.write(OutputStream.java:167)
> |  Restore definitions with: /reload -restore   at java.base/java.io.OutputStream.write(OutputStream.java:124)
> 
>         at jdk.jshell/jdk.jshell.execution.DemultiplexInput.run(DemultiplexInput.java:74)
> 
> jshell> System.console().writer().println("?????")
> ?????
> 
> 
> After (master & without https://github.com/openjdk/jdk/pull/24438):
> 
> 
> jshell> IO.println("a".repeat(128))
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> 
> jshell> IO.println("?????")
> ?????
> 
> jshell> System.console().writer().println("a".repeat(128))
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> 
> jshell> System.console().writer().println("?????")
> ?????
> 
> 
> I don't know how to prepare the template other PRs use or whether outsiders like me may create a PR.

This pull request has now been integrated.

Changeset: c8ce61c8
Author:    Tatsunori Uchino <tats.u at live.jp>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8ce61c8cadaf0371dc490c76b753f98bbaa118a
Stats:     29 lines in 2 files changed: 27 ins; 0 del; 2 mod

8355371: NegativeArraySizeException in print methods in IO or System.console() in JShell
8354910: Output by java.io.IO or System.console() corrupted for some non-ASCII characters

Reviewed-by: liach, jlahoda

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

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

From jlahoda at openjdk.org  Mon May  5 09:03:53 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 May 2025 09:03:53 GMT
Subject: Integrated: 8299934: LocalExecutionControl replaces default uncaught
 exception handler
In-Reply-To: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
References: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>
Message-ID: <nAPJIgJEJV5jsT54UAPBVGXsDKR8R0cgAbyUn7U0lAQ=.00ca2dc1-d826-4a69-bb3e-280867371ae2@github.com>

On Fri, 10 Mar 2023 19:48:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The JShell's `LocalExecutionControl` set the global default uncaught exception handler, causing problems to external code that might rely on it (even if only for logging/debugging purposes).
> 
> The proposal here is to do what the bug is suggesting, and only handling the exception inside the `ThreadGroup` that JShell creates. The patch does not strive to do further changes to how the exception handling is done.

This pull request has now been integrated.

Changeset: f1e06c3c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1e06c3c050b3440555d63b6de80fe9f60b35dfa
Stats:     179 lines in 2 files changed: 165 ins; 10 del; 4 mod

8299934: LocalExecutionControl replaces default uncaught exception handler

Reviewed-by: liach

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

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

From jlahoda at openjdk.org  Wed May  7 06:49:27 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 7 May 2025 06:49:27 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ??
Message-ID: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>

When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.

The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.

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

Commit messages:
 - Fixing tests.
 - 8356165: System.in in jshell replace supplementary characters with ??

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

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

From cstein at openjdk.org  Wed May  7 10:33:15 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 7 May 2025 10:33:15 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ??
In-Reply-To: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
Message-ID: <TGgUTbaM0fdjRSBREcNbITl6KO-NJoR5Z-cCpk1X3hQ=.98daa835-3f00-4b01-b287-3434012fbf73@github.com>

On Wed, 7 May 2025 06:44:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
> 
> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java line 980:

> 978:         if (pendingBytes == null || pendingBytes.length <= pendingBytesPointer) {
> 979:             char userChar = readUserInputChar();
> 980:             StringBuilder dataToConvert = new StringBuilder();

Perhaps, add here the comment from the PR description for readers from the future:

> [...] when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.

The (internal) API used in the implementation doesn't express that on first sight.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2077326550

From duke at openjdk.org  Thu May  8 14:58:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 8 May 2025 14:58:54 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ??
In-Reply-To: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
Message-ID: <gF85bYpA5x1aMcX1Ec_GifvbvtB782iUYw5JSajJxzo=.47e17fe8-8c5f-40d1-a13f-f43d3e4d5949@github.com>

On Wed, 7 May 2025 06:44:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
> 
> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java line 986:

> 984:                     Character.isLowSurrogate(pendingLine.charAt(pendingLinePointer))) {
> 985:                     dataToConvert.append(readUserInputChar());
> 986:                 }

How about combining `readUserInputChar()` and `pendingLinePointer--`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2079889528

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for change
 of default timeout factor
Message-ID: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>

This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).

The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have plown through testcases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

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

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

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

From duke at openjdk.org  Thu May  8 15:23:51 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Thu, 8 May 2025 15:23:51 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ??
In-Reply-To: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
Message-ID: <IQUmLmXT3Nq7TVxNq0KF6qW-XwgzRHEy957vUq9iM38=.e2313ce9-0360-4338-84e2-191d8553ccfb@github.com>

On Wed, 7 May 2025 06:44:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
> 
> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.

test/langtools/jdk/jshell/InputUITest.java line 53:

> 51:         doRunTest((inputSink, out) -> {
> 52:             inputSink.write("new String(System.in.readNBytes(4))\n\uD83D\uDE03\n");
> 53:             waitOutput(out, "\"\uD83D\uDE03\"");

Can the current implementation pass the following test?


-            inputSink.write("new String(System.in.readNBytes(4))\n\uD83D\uDE03\n");
-            waitOutput(out, ""\uD83D\uDE03"");
+            inputSink.write("new String(System.in.readNBytes(5))\n\uD83D\uDE031\n");
+            waitOutput(out, ""\uD83D\uDE031"");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2079939731

From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

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

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <VKBSy10yl0qvIk0P_JQb3KGFkmaDEtWYzncAlEW7VV8=.bd136181-45be-437e-b684-2ad16ac419b5@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
Tests have not finished running - but I already see one intermittent failure:
`java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
Message-ID: <inHeApQE1qTo35yQi6vzs6LYuATsr8NxmEMOU_1x_5c=.6ea734d1-63f2-47dc-a245-23d3233c76e4@github.com>

On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
Message-ID: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
Message-ID: <P_bn9YLGadoCvpQ4U3pQCWqa_FgbqOs_Smf_TRfTUxw=.5db4086c-fef8-437b-aa77-26124ea44177@github.com>

On Fri, 9 May 2025 04:54:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <togAOydR2ZGmRMpEDKHz7PXzdWIRLYaU6sFIlHUXUw4=.cdb2a446-5f7c-438e-8f1e-2d8bad8c9327@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <uabWdORniwCo0BELgwEHL9xwszL7WvN02cMLTu253K4=.de2529aa-23d2-4c86-9133-504f4146c93e@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
Message-ID: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race <prr at openjdk.org> wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: <LWO7Q1kcmK2ygzbo5WovS47Dbuj_vfNTrTCvtPe8eLs=.4247df94-1d6d-4be7-bd56-77257bea18f7@github.com>

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
Message-ID: <rN9e2v3Ja1Kz4w4CsS6pDyFKNs88tAacAG4wiwWaK6w=.abf1d75b-861b-4de9-8e7b-61deca3e5e05@github.com>

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <vhPQ5uxCX4mkm_a34_Elnbjxazr49tOXu_ezw8YbY_g=.81d3c926-7a82-4f4a-95b2-336c63350801@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <d4WeSYdxBsFQG_bsWZgsyGDKPbRL5ks8pTVVkck5foc=.5f39ab1e-bbab-483c-8b19-568c6e5a80e4@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <zfwQsPX7kHwfbD2VUx3dhQwyy1VjAsb-yITfpShYhLM=.2c91dacc-78e2-4393-a7c5-b196fb5be962@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <tWgLVluDO0fcZ3e9N1V1GU6rmEcz-tyTVkNuJdr06Pw=.749ad3d3-b55a-486b-8d74-40091899e657@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > test/jdk/java/awt/font/NumericShaper/MTTest.java
> > ```
> > * * @run main/timeout=300/othervm MTTest
> > 
> > 
> > * * @run main/timeout=1200/othervm MTTest
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> > So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From jlahoda at openjdk.org  Mon May 12 13:59:11 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 May 2025 13:59:11 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v2]
In-Reply-To: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
Message-ID: <Frbmfz5qhagQODgPydVu_njYDbb8J03qHy2aXHLpDbI=.bf96c424-5a6f-4e32-98c9-47c67e3a4002@github.com>

> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
> 
> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.

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

  Reflecting review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25079/files
  - new: https://git.openjdk.org/jdk/pull/25079/files/42052fcb..a81e2265

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

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

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

From jlahoda at openjdk.org  Mon May 12 16:37:10 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 May 2025 16:37:10 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
Message-ID: <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>

> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
> 
> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.

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

  (Attempting to) fix the test on Windows.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25079/files
  - new: https://git.openjdk.org/jdk/pull/25079/files/a81e2265..3f7fd5c2

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

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

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

From duke at openjdk.org  Mon May 12 22:56:51 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Mon, 12 May 2025 22:56:51 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
Message-ID: <8gHkpGeyh2DrQMNTuWOeLIFYxwezq2QY0TvgO1b0HGg=.8fe8d442-737a-4625-aabe-dcd3f4465d6d@github.com>

On Mon, 12 May 2025 16:37:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
>> 
>> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (Attempting to) fix the test on Windows.

I forgot to explain the context: 

- Increment of the number of input bytes to be read is to assure that a byte or code unit is not read twice or skipped
- Providing extra input is to prevent  the suspension due to the input starvation (especially for builds without this fix)

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

PR Comment: https://git.openjdk.org/jdk/pull/25079#issuecomment-2874398072

From jlahoda at openjdk.org  Tue May 13 11:53:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 13 May 2025 11:53:52 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <8gHkpGeyh2DrQMNTuWOeLIFYxwezq2QY0TvgO1b0HGg=.8fe8d442-737a-4625-aabe-dcd3f4465d6d@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
 <8gHkpGeyh2DrQMNTuWOeLIFYxwezq2QY0TvgO1b0HGg=.8fe8d442-737a-4625-aabe-dcd3f4465d6d@github.com>
Message-ID: <VFCotlVfDreyZUlrdNuz0ZNCw3qzjPwuJNyo14Oh7HE=.0bce40c7-9ed1-4e6b-9229-a01f501a2349@github.com>

On Mon, 12 May 2025 22:54:30 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> I forgot to explain the context:
> 
>     * Increment of the number of input bytes to be read is to assure that a byte or code unit is not read twice or skipped
> 
>     * Providing extra input is to prevent  the suspension due to the input starvation (especially for builds without this fix)

I missed the additional `1` there. But, I think the current code, although more complex, satisfies the constraints as well (we are reading the end-of-line, and checking for it).

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

PR Comment: https://git.openjdk.org/jdk/pull/25079#issuecomment-2876199815

From duke at openjdk.org  Tue May 13 14:32:52 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Tue, 13 May 2025 14:32:52 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
Message-ID: <ESZxahtt64vrfZAaL_gl9FHP3XWZxH9ZDUm6nXt8CWk=.73ea7fe7-8272-4609-841a-e38385eeae20@github.com>

On Mon, 12 May 2025 16:37:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
>> 
>> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (Attempting to) fix the test on Windows.

I will believe you have considered the difference of the length of EOL in Windows and Unix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25079#issuecomment-2876763943

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: RFR: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <ExI4OcZ4H03w2Kmpe35WuEynczPvNAcXjCFY4cd6ldg=.1be29db4-e6a7-4376-93d9-94c05587c721@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

After an offline discussion, we agreed to wait a bit with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for
 change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <LrGk5ztc6aRY4EQjv-mVBVaNIVBhvjY-SQD1ZkUD5d4=.dba136cb-acc9-4d18-9112-41f62464a65f@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

This pull request has been closed without being integrated.

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

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

From naoto at openjdk.org  Sat May 17 00:13:05 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 17 May 2025 00:13:05 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
Message-ID: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>

`java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

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

Commit messages:
 - Tests read* method variations
 - Merge branch 'master' into JDK-8356985-Use-stdin-encoding-in-Console
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25271/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25271&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356985
  Stats: 270 lines in 11 files changed: 241 ins; 3 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/25271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271

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

From jlahoda at openjdk.org  Mon May 19 09:53:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 09:53:54 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <ESZxahtt64vrfZAaL_gl9FHP3XWZxH9ZDUm6nXt8CWk=.73ea7fe7-8272-4609-841a-e38385eeae20@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
 <ESZxahtt64vrfZAaL_gl9FHP3XWZxH9ZDUm6nXt8CWk=.73ea7fe7-8272-4609-841a-e38385eeae20@github.com>
Message-ID: <aL9q_hXLMfjI0S_fMidh2meSkQL8AKFw3g5GLzf03PE=.cc5d1277-7c1f-4ffa-ab80-b75557c122b1@github.com>

On Tue, 13 May 2025 14:30:11 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

> I will believe you have considered the difference of the length of EOL in Windows and Unix.

Yes, the test handles both Unix and Windows EOL (that's the complicating factor).

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

PR Comment: https://git.openjdk.org/jdk/pull/25079#issuecomment-2890385822

From duke at openjdk.org  Mon May 19 10:13:52 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Mon, 19 May 2025 10:13:52 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
Message-ID: <Tv5jvej6Wmj8Q6XV_6pT8MHc3qGeMDNu7xhgBm-HaE4=.26d11bc3-9a26-4e06-a3c6-d980300a92b8@github.com>

On Mon, 12 May 2025 16:37:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
>> 
>> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (Attempting to) fix the test on Windows.

I suspect I've been misunderstood the argument for `readNBytes` in the test case. Sorry to have bothered you.

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

PR Comment: https://git.openjdk.org/jdk/pull/25079#issuecomment-2890451320

From cstein at openjdk.org  Mon May 19 11:08:56 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 19 May 2025 11:08:56 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <TGgUTbaM0fdjRSBREcNbITl6KO-NJoR5Z-cCpk1X3hQ=.98daa835-3f00-4b01-b287-3434012fbf73@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <TGgUTbaM0fdjRSBREcNbITl6KO-NJoR5Z-cCpk1X3hQ=.98daa835-3f00-4b01-b287-3434012fbf73@github.com>
Message-ID: <5WrI1O8cqR6hvnECNbtACKEzPhobQzYlcE5HCzz7xMc=.f1ba5923-822a-4340-aec8-4770bd3fcb9d@github.com>

On Wed, 7 May 2025 10:31:02 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (Attempting to) fix the test on Windows.
>
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java line 980:
> 
>> 978:         if (pendingBytes == null || pendingBytes.length <= pendingBytesPointer) {
>> 979:             char userChar = readUserInputChar();
>> 980:             StringBuilder dataToConvert = new StringBuilder();
> 
> Perhaps, add here the comment from the PR description for readers from the future:
> 
>> [...] when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.
> 
> The (internal) API used in the implementation doesn't express that on first sight.

Thanks for adding comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2095459321

From cstein at openjdk.org  Mon May 19 11:13:52 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 19 May 2025 11:13:52 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
Message-ID: <ljs3Z48GkcmPHpOPMuePDcxsOKXrgaKr40i5Q4ZnjRw=.39a2db4a-7392-4f30-9cc5-9801c9c74699@github.com>

On Mon, 12 May 2025 16:37:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
>> 
>> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (Attempting to) fix the test on Windows.

Looks good to me.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25079#pullrequestreview-2850373101

From nbenalla at openjdk.org  Mon May 19 11:34:26 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 19 May 2025 11:34:26 GMT
Subject: RFR: 8356633: Incorrect use of {@link} in jdk.jshell
Message-ID: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>

Please review this patch to fix some javadoc bugs.

TIA

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

Commit messages:
 - (C)
 - fix incorrect `@link` tags

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

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

From asotona at openjdk.org  Mon May 19 11:36:53 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 19 May 2025 11:36:53 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
Message-ID: <n3wI4QGLbbLOjez4nBEAhjH68nNCLloHbhq1nUV-F9A=.fe83d48d-6690-4295-809e-0038c74f0d60@github.com>

On Mon, 12 May 2025 16:37:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
>> 
>> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (Attempting to) fix the test on Windows.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25079#pullrequestreview-2850435285

From duke at openjdk.org  Mon May 19 12:16:54 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Mon, 19 May 2025 12:16:54 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
Message-ID: <KkTLmoqSpbAEMsG898pChq7sw4ZQqEnFhFUFL46WS-w=.d60b9399-ed3a-4966-9b1c-4c19f92d5a33@github.com>

On Mon, 12 May 2025 16:37:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
>> 
>> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (Attempting to) fix the test on Windows.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java line 980:

> 978:         if (pendingBytes == null || pendingBytes.length <= pendingBytesPointer) {
> 979:             char userChar = readUserInputChar();
> 980:             StringBuilder dataToConvert = new StringBuilder();

FWIW I think we can avoid using StringBuilder (and make the code more RAM-friendly):


char[] dataToConvert = { useChar, '\0' };
// if (...) {
// ...
// if (...) {
// ...
dataToConvert[1] = lowSurrogate;
// }
// ...
// }
// low-surrogate code unit never be null char
pendingBytes = dataToConvert[1] != '\0' ? String.valueOf(dataToConvert) : String.valueOf(dataToConvert[0]);


The next version of .NET is said to be able to allocate such a tiny array to the stack, instead of the heap, but I don't know whether JVM can do the same optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2095569619

From duke at openjdk.org  Mon May 19 12:32:53 2025
From: duke at openjdk.org (xxDark)
Date: Mon, 19 May 2025 12:32:53 GMT
Subject: RFR: 8353487: JShell LocalExecutionControl should allow decorating
 the execution task [v2]
In-Reply-To: <Rq2viLuxGoKgwIChgpF1kA6Yn6BvJ9PojcFdVYc_Clo=.bda99a31-337c-476a-a6a6-11090fb94805@github.com>
References: <pHDQYr9-TPcRILXosAhrbBycdyeAQlVmNrYmC4X66c4=.6469dfad-15be-49d7-a3be-66a8ac3aecc5@github.com>
 <Rq2viLuxGoKgwIChgpF1kA6Yn6BvJ9PojcFdVYc_Clo=.bda99a31-337c-476a-a6a6-11090fb94805@github.com>
Message-ID: <EaU1FEJ_yKbYgbUgGLvjs17uiPteb4_XWwOdwkzPbxU=.adf9d708-2f04-467d-93cc-dfcb80758484@github.com>

On Fri, 4 Apr 2025 16:55:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR adds the ability for subclasses of JShell's `LocalExecutionControl` to configure thread-local context in the execution thread that snippets execute in. Please see [JDK-8353487](https://bugs.openjdk.org/browse/JDK-8353487) for more details & rationale.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace decorateExecution() with doInvoke() per review suggestion.

import jdk.jshell.execution.LocalExecutionControl;

import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class LocalExecutionControlTest {

    public static void main(String[] args) throws Throwable {
        var control = new LocalExecutionControl((ClassLoader) null) {
            Object result;

            @Override
            protected Object doInvoke(Method method) throws IllegalAccessException, InvocationTargetException {
                return result = super.doInvoke(method);
            }
        };
        control.doInvoke(MethodHandles.class.getDeclaredMethod("lookup"));
        var lookup = (MethodHandles.Lookup) control.result;
        var unsafeClass = Class.forName("jdk.internal.misc.Unsafe");
        var unsafe = lookup.findStatic(unsafeClass, "getUnsafe", MethodType.methodType(unsafeClass)).invoke();
        var field = MethodHandles.Lookup.class.getDeclaredField("IMPL_LOOKUP");
        lookup = (MethodHandles.Lookup) lookup.findVirtual(unsafeClass, "getReference", MethodType.methodType(Object.class, Object.class, long.class))
                .invoke(
                        unsafe,
                        lookup.findVirtual(unsafeClass, "staticFieldBase", MethodType.methodType(Object.class, Field.class)).invoke(unsafe, field),
                        (long) lookup.findVirtual(unsafeClass, "staticFieldOffset", MethodType.methodType(long.class, Field.class)).invoke(unsafe, field)
                );
        System.out.println(lookup);
    }
}

https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/java.base/share/classes/module-info.java#L204-L222
Please reconsider use of reflection (or method handles)
I was looking into jshell before to achieve something like this using https://github.com/openjdk/jdk/blob/3acfa9e4e7be2f37ac55f97348aad4f74ba802a0/src/jdk.jshell/share/classes/jdk/jshell/execution/DirectExecutionControl.java#L125 that exposes accessible `java.lang.reflect.Method` to user code, but it was not possible to get back the invocation result. With this PR, it is now possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/24398#issuecomment-2890837027

From jlahoda at openjdk.org  Mon May 19 12:55:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 12:55:52 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <KkTLmoqSpbAEMsG898pChq7sw4ZQqEnFhFUFL46WS-w=.d60b9399-ed3a-4966-9b1c-4c19f92d5a33@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
 <KkTLmoqSpbAEMsG898pChq7sw4ZQqEnFhFUFL46WS-w=.d60b9399-ed3a-4966-9b1c-4c19f92d5a33@github.com>
Message-ID: <yn_Un3WfIzj7y9ivS0QplxNFTenH2cYFMCBNaIt2p4c=.5e2fc189-8321-43fa-9546-d9e08228cef1@github.com>

On Mon, 19 May 2025 12:11:46 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (Attempting to) fix the test on Windows.
>
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java line 980:
> 
>> 978:         if (pendingBytes == null || pendingBytes.length <= pendingBytesPointer) {
>> 979:             char userChar = readUserInputChar();
>> 980:             StringBuilder dataToConvert = new StringBuilder();
> 
> FWIW I think we can avoid using StringBuilder (and make the code more RAM-friendly):
> 
> 
> char[] dataToConvert = { useChar, '\0' };
> // if (...) {
> // ...
> // if (...) {
> // ...
> dataToConvert[1] = lowSurrogate;
> // }
> // ...
> // }
> // low-surrogate code unit never be null char
> pendingBytes = dataToConvert[1] != '\0' ? String.valueOf(dataToConvert) : String.valueOf(dataToConvert[0]);
> 
> 
> The next version of .NET is said to be able to allocate such a tiny array to the stack, instead of the heap, but I don't know whether JVM can do the same optimization.

We could do something like that, although I wrote it as I wrote it mostly because that's more clearly correct. Although the current tests probably cover all the cases, so with a bit of work, we probably could eliminate the (explicit) array completely.

Overall, on most places, it is usually not necessary to be too clever - the VM can optimize and eliminate allocations if needed.

I'll leave it up to Adam and/or Christian whether they would prefer a slightly more complex code with less (explicit/visible) allocation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2095646697

From jlahoda at openjdk.org  Mon May 19 13:12:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 May 2025 13:12:55 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <yn_Un3WfIzj7y9ivS0QplxNFTenH2cYFMCBNaIt2p4c=.5e2fc189-8321-43fa-9546-d9e08228cef1@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
 <KkTLmoqSpbAEMsG898pChq7sw4ZQqEnFhFUFL46WS-w=.d60b9399-ed3a-4966-9b1c-4c19f92d5a33@github.com>
 <yn_Un3WfIzj7y9ivS0QplxNFTenH2cYFMCBNaIt2p4c=.5e2fc189-8321-43fa-9546-d9e08228cef1@github.com>
Message-ID: <yM5SjYsu8bw9tWLynfCc_3fLF_Hg1-1PVs5mTyb4kpc=.c2f470e7-015f-4e48-965b-a4a035c12fd7@github.com>

On Mon, 19 May 2025 12:52:51 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java line 980:
>> 
>>> 978:         if (pendingBytes == null || pendingBytes.length <= pendingBytesPointer) {
>>> 979:             char userChar = readUserInputChar();
>>> 980:             StringBuilder dataToConvert = new StringBuilder();
>> 
>> FWIW I think we can avoid using StringBuilder (and make the code more RAM-friendly):
>> 
>> 
>> char[] dataToConvert = { useChar, '\0' };
>> // if (...) {
>> // ...
>> // if (...) {
>> // ...
>> dataToConvert[1] = lowSurrogate;
>> // }
>> // ...
>> // }
>> // low-surrogate code unit never be null char
>> pendingBytes = dataToConvert[1] != '\0' ? String.valueOf(dataToConvert) : String.valueOf(dataToConvert[0]);
>> 
>> 
>> The next version of .NET is said to be able to allocate such a tiny array to the stack, instead of the heap, but I don't know whether JVM can do the same optimization.
>
> We could do something like that, although I wrote it as I wrote it mostly because that's more clearly correct. Although the current tests probably cover all the cases, so with a bit of work, we probably could eliminate the (explicit) array completely.
> 
> Overall, on most places, it is usually not necessary to be too clever - the VM can optimize and eliminate allocations if needed.
> 
> I'll leave it up to Adam and/or Christian whether they would prefer a slightly more complex code with less (explicit/visible) allocation.

FWIW, we could do this:
https://github.com/lahodaj/jdk/commit/6a07648829ee8df263cf3fc1c55055fe45d4eb17

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2095681607

From asotona at openjdk.org  Mon May 19 13:26:54 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 19 May 2025 13:26:54 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <yM5SjYsu8bw9tWLynfCc_3fLF_Hg1-1PVs5mTyb4kpc=.c2f470e7-015f-4e48-965b-a4a035c12fd7@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
 <KkTLmoqSpbAEMsG898pChq7sw4ZQqEnFhFUFL46WS-w=.d60b9399-ed3a-4966-9b1c-4c19f92d5a33@github.com>
 <yn_Un3WfIzj7y9ivS0QplxNFTenH2cYFMCBNaIt2p4c=.5e2fc189-8321-43fa-9546-d9e08228cef1@github.com>
 <yM5SjYsu8bw9tWLynfCc_3fLF_Hg1-1PVs5mTyb4kpc=.c2f470e7-015f-4e48-965b-a4a035c12fd7@github.com>
Message-ID: <1ecgKzC2XazFjLF_GIjonIp0DpkZ-FQJ9sLaGiJgAlU=.d1b3ff43-c340-47a0-9ba4-adbcf73e145e@github.com>

On Mon, 19 May 2025 13:10:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> We could do something like that, although I wrote it as I wrote it mostly because that's more clearly correct. Although the current tests probably cover all the cases, so with a bit of work, we probably could eliminate the (explicit) array completely.
>> 
>> Overall, on most places, it is usually not necessary to be too clever - the VM can optimize and eliminate allocations if needed.
>> 
>> I'll leave it up to Adam and/or Christian whether they would prefer a slightly more complex code with less (explicit/visible) allocation.
>
> FWIW, we could do this:
> https://github.com/lahodaj/jdk/commit/6a07648829ee8df263cf3fc1c55055fe45d4eb17

Readability of the code is my preference unless the performance is absolutely critical (not this case).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2095709647

From duke at openjdk.org  Mon May 19 14:40:51 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Mon, 19 May 2025 14:40:51 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <1ecgKzC2XazFjLF_GIjonIp0DpkZ-FQJ9sLaGiJgAlU=.d1b3ff43-c340-47a0-9ba4-adbcf73e145e@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
 <KkTLmoqSpbAEMsG898pChq7sw4ZQqEnFhFUFL46WS-w=.d60b9399-ed3a-4966-9b1c-4c19f92d5a33@github.com>
 <yn_Un3WfIzj7y9ivS0QplxNFTenH2cYFMCBNaIt2p4c=.5e2fc189-8321-43fa-9546-d9e08228cef1@github.com>
 <yM5SjYsu8bw9tWLynfCc_3fLF_Hg1-1PVs5mTyb4kpc=.c2f470e7-015f-4e48-965b-a4a035c12fd7@github.com>
 <1ecgKzC2XazFjLF_GIjonIp0DpkZ-FQJ9sLaGiJgAlU=.d1b3ff43-c340-47a0-9ba4-adbcf73e145e@github.com>
Message-ID: <AK8lO32zWN2UYd5JZBiMPsdzttVmuLCno7rgh6HoCuU=.4902a8df-a440-46ac-a6aa-ac99fd39afda@github.com>

On Mon, 19 May 2025 13:24:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> FWIW, we could do this:
>> https://github.com/lahodaj/jdk/commit/6a07648829ee8df263cf3fc1c55055fe45d4eb17
>
> Readability of the code is my preference unless the performance is absolutely critical (not this case).

> https://github.com/lahodaj/jdk/commit/6a07648829ee8df263cf3fc1c55055fe45d4eb17

Better than my suggestion.

The current code using StringBuilder is not bad because the act to pass a very long string to JShell seems to be something like shooting ourselves in the foot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2095867746

From acobbs at openjdk.org  Mon May 19 15:25:55 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 19 May 2025 15:25:55 GMT
Subject: RFR: 8353487: JShell LocalExecutionControl should allow decorating
 the execution task [v2]
In-Reply-To: <EaU1FEJ_yKbYgbUgGLvjs17uiPteb4_XWwOdwkzPbxU=.adf9d708-2f04-467d-93cc-dfcb80758484@github.com>
References: <pHDQYr9-TPcRILXosAhrbBycdyeAQlVmNrYmC4X66c4=.6469dfad-15be-49d7-a3be-66a8ac3aecc5@github.com>
 <Rq2viLuxGoKgwIChgpF1kA6Yn6BvJ9PojcFdVYc_Clo=.bda99a31-337c-476a-a6a6-11090fb94805@github.com>
 <EaU1FEJ_yKbYgbUgGLvjs17uiPteb4_XWwOdwkzPbxU=.adf9d708-2f04-467d-93cc-dfcb80758484@github.com>
Message-ID: <2zAnHR37WRcUPHtGBHvkPjWJU5u661A9UFdxXi9ZNIQ=.ec732b89-b96b-4342-8cf1-768f7a487d7a@github.com>

On Mon, 19 May 2025 12:30:21 GMT, xxDark <duke at openjdk.org> wrote:

> that exposes accessible `java.lang.reflect.Method` to user code, but it was not possible to get back the invocation result. With this PR, it is now possible.

Good point. I believe my [original patch](https://github.com/openjdk/jdk/compare/master...68cccbf18ab1dea51e3e673523e77a19cc221b82) which adds a `protected Runnable decorateExecution(Runnable)` method instead did not have this issue, so we could just revert to that approach.

Or there is the other approach (previously mentioned) which adds `executionStart()` and `executionFinish()` methods and should also be safe.

@lahodaj what's your opinion here?

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/24398#issuecomment-2891433102

From duke at openjdk.org  Tue May 20 03:47:52 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Tue, 20 May 2025 03:47:52 GMT
Subject: RFR: 8356165: System.in in jshell replace supplementary characters
 with ?? [v3]
In-Reply-To: <AK8lO32zWN2UYd5JZBiMPsdzttVmuLCno7rgh6HoCuU=.4902a8df-a440-46ac-a6aa-ac99fd39afda@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
 <lpVT6fl8pBBTQz5-ewHtTTSc3li1N6XSx4Wk6IHaIWg=.ffb03237-a9b8-429c-bad9-9c2cac0e0d9e@github.com>
 <KkTLmoqSpbAEMsG898pChq7sw4ZQqEnFhFUFL46WS-w=.d60b9399-ed3a-4966-9b1c-4c19f92d5a33@github.com>
 <yn_Un3WfIzj7y9ivS0QplxNFTenH2cYFMCBNaIt2p4c=.5e2fc189-8321-43fa-9546-d9e08228cef1@github.com>
 <yM5SjYsu8bw9tWLynfCc_3fLF_Hg1-1PVs5mTyb4kpc=.c2f470e7-015f-4e48-965b-a4a035c12fd7@github.com>
 <1ecgKzC2XazFjLF_GIjonIp0DpkZ-FQJ9sLaGiJgAlU=.d1b3ff43-c340-47a0-9ba4-adbcf73e145e@github.com>
 <AK8lO32zWN2UYd5JZBiMPsdzttVmuLCno7rgh6HoCuU=.4902a8df-a440-46ac-a6aa-ac99fd39afda@github.com>
Message-ID: <KtNbQqjXY-OFgoH-1oskgDdPfB5q3CabgW4p8MUFWgk=.84b52ed2-d059-4ce6-bd9e-7f40f733f947@github.com>

On Mon, 19 May 2025 14:38:21 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Readability of the code is my preference unless the performance is absolutely critical (not this case).
>
>> https://github.com/lahodaj/jdk/commit/6a07648829ee8df263cf3fc1c55055fe45d4eb17
> 
> Better than my suggestion.
> 
> The current code using StringBuilder is not bad because the act to pass a very long string to JShell seems to be something like shooting ourselves in the foot.

You can /integrate the current code with StringBuilder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25079#discussion_r2096814538

From jlahoda at openjdk.org  Tue May 20 06:07:01 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 May 2025 06:07:01 GMT
Subject: Integrated: 8356165: System.in in jshell replace supplementary
 characters with ??
In-Reply-To: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
References: <NzuTiW4IdqLkPMhYVHvokGvt8iubA_4KX3OM2fkSNnM=.1b6f5922-c61c-4ec4-aa5b-22a429ca6706@github.com>
Message-ID: <fP6KMlg1szdXLdxx_REnKoxIL1d7lslN6tg4lpiqe5E=.66b063fa-b94d-40e0-b056-825e2690be8b@github.com>

On Wed, 7 May 2025 06:44:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When reading from `System.in` in a JShell snippet, JShell first reads the whole line (getting a `String`), and then converts this characters from this `String` to bytes on demand. But, it does not convert multi-surrogate code points correctly, it tries to convert each surrogate separately, which cannot work.
> 
> The proposal herein is to, when the current character is a high surrogate, peek at the next character, and if it is a low surrogate, convert both the high and low surrogates to bytes together.

This pull request has now been integrated.

Changeset: e961b13c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e961b13cd68bc352b86af17c7e53df8537519beb
Stats:     92 lines in 3 files changed: 88 ins; 0 del; 4 mod

8356165: System.in in jshell replace supplementary characters with ??

Reviewed-by: cstein, asotona

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

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

From vyazici at openjdk.org  Tue May 20 11:34:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 May 2025 11:34:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>

On Fri, 16 May 2025 18:11:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

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

> 558:     static final Charset STDIN_CHARSET =
> 559:         Charset.forName(System.getProperty("stdin.encoding"), UTF_8.INSTANCE);
> 560:     static final Charset STDOUT_CHARSET =

I guess these can be marked `private`?

Suggestion:

    private static final Charset STDIN_CHARSET =
        Charset.forName(System.getProperty("stdin.encoding"), UTF_8.INSTANCE);
    private static final Charset STDOUT_CHARSET =

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

> 158: 
> 159:             try {
> 160:                 Terminal terminal = TerminalBuilder.builder().encoding(outCharset)

Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants?

test/jdk/java/io/Console/CharsetTest.java line 1:

> 1: /*

Copyright year update is missing.

test/jdk/java/io/Console/StdinEncodingTest.java line 46:

> 44:  * @run junit StdinEncodingTest
> 45:  */
> 46: public class StdinEncodingTest {

AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.)

test/jdk/java/io/Console/StdinEncodingTest.java line 49:

> 47: 
> 48:     @Test
> 49:     @EnabledOnOs({OS.LINUX, OS.MAC})

Shall we replace `@EnabledOnOs` with the `@requires (os.family == "linux" | os.family == "mac")` JTreg directive instead per [JDK-8211673](https://bugs.openjdk.org/browse/JDK-8211673)?

test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 36:

> 34: 
> 35: // A test charset provider that decodes every input byte into its uppercase
> 36: public class MockCharsetProvider extends CharsetProvider {

*Nit:* Maybe a more self-explanatory name, e.g., `UpperCasingCharsetProvider`?

test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 83:

> 81:             while (in.remaining() > 0) {
> 82:                 char c = (char)in.get();
> 83:                 if (c != '\n') {

`Character.toUpperCase('\n') == '\n'`, not? If so, do we still need this `if`-branching?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097641573
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097630717
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097578092
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097718253
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097671831
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097711653
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2097704883

From jlahoda at openjdk.org  Tue May 20 13:12:28 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 May 2025 13:12:28 GMT
Subject: RFR: 8347050: Console.readLine() drops '\' when reading through JLine
Message-ID: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>

JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().

This PR proposes to disable the history expansion.

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

Commit messages:
 - Adding bug number
 - 8347050: Console.readLine() drops '\' when reading through JLine

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

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

From jlahoda at openjdk.org  Tue May 20 13:34:01 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 May 2025 13:34:01 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages
Message-ID: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>

JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.

The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.

This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.

The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.

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

Commit messages:
 - Attempting to fix test failures.
 - Clarifying duration, as suggested.
 - 8356245: stdin.encoding and stdout.encoding in jshell don't respect console code pages

Changes: https://git.openjdk.org/jdk/pull/25328/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25328&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356245
  Stats: 24 lines in 3 files changed: 13 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25328/head:pull/25328

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

From cstein at openjdk.org  Tue May 20 13:45:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 20 May 2025 13:45:51 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages
In-Reply-To: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
Message-ID: <eXxeb8ZTq7185pvj5zuHG6AoNpoA3txHHAi77Y--6zw=.735ca03b-c6e9-4a21-96f1-b37cbf8dc19f@github.com>

On Tue, 20 May 2025 13:28:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
> 
> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
> 
> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
> 
> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.

src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java line 73:

> 71: public class JdiDefaultExecutionControl extends JdiExecutionControl {
> 72: 
> 73:     private static final Duration SHUTDOWN_TIMEOUT = Duration.ofSeconds(1);

Nice!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25328#discussion_r2098012438

From vyazici at openjdk.org  Tue May 20 19:20:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 May 2025 19:20:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
In-Reply-To: <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
Message-ID: <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>

On Tue, 20 May 2025 10:40:39 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 160:
> 
>> 158: 
>> 159:             try {
>> 160:                 Terminal terminal = TerminalBuilder.builder().encoding(outCharset)
> 
> Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants?

Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098698322

From vyazici at openjdk.org  Tue May 20 19:26:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 20 May 2025 19:26:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
In-Reply-To: <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
Message-ID: <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>

On Tue, 20 May 2025 19:18:43 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 160:
>> 
>>> 158: 
>>> 159:             try {
>>> 160:                 Terminal terminal = TerminalBuilder.builder().encoding(outCharset)
>> 
>> Shouldn't ideally `JdkConsole::charset` and `Terminal::encoding` be adapted for stdin/stdout variants?
>
> Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings.

All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention:

src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java
src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098707061

From naoto at openjdk.org  Tue May 20 21:57:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 21:57:45 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

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

  Reflects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25271/files
  - new: https://git.openjdk.org/jdk/pull/25271/files/f2eb1ad8..ec420654

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

  Stats: 218 lines in 7 files changed: 108 ins; 93 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/25271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271

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

From naoto at openjdk.org  Tue May 20 22:06:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 22:06:50 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
 <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
Message-ID: <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>

On Tue, 20 May 2025 19:24:16 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Also noticed `DumbTerminalProvider::sysTerminal` calls `DumbTerminal` with `new FileInputStream(FileDescriptor.in)`. Later on `DumbTerminal` applies `encoding()` both for passed `stdin` and `std{out,err}`. In short, `TerminalProvider` might need to undergo a similar refactoring separating input and output encodings.
>
> All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention:
> 
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java
> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java

JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947104

From naoto at openjdk.org  Tue May 20 22:06:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 22:06:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
Message-ID: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>

On Tue, 20 May 2025 11:29:42 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> test/jdk/java/io/Console/StdinEncodingTest.java line 46:
> 
>> 44:  * @run junit StdinEncodingTest
>> 45:  */
>> 46: public class StdinEncodingTest {
> 
> AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.)

`stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java`

> test/jdk/java/io/Console/csp/provider/MockCharsetProvider.java line 83:
> 
>> 81:             while (in.remaining() > 0) {
>> 82:                 char c = (char)in.get();
>> 83:                 if (c != '\n') {
> 
> `Character.toUpperCase('\n') == '\n'`, not? If so, do we still need this `if`-branching?

Eliminating newlines was a hack to ignore them in the expect responses so that it can check the combined output in one shot. Now I think it is better to check the result separately, so modified as such.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947409
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2098947338

From jlu at openjdk.org  Wed May 21 06:28:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 21 May 2025 06:28:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
Message-ID: <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>

On Tue, 20 May 2025 21:57:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

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

> 65:  * stdout.encoding}, in which case read operations use the {@code Charset}
> 66:  * designated by {@code stdin.encoding}.
> 67:  * <p>

`Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well.

test/jdk/java/io/Console/StdinEncodingTest.java line 38:

> 36:  * @test
> 37:  * @bug 8356985
> 38:  * @summary Tests if "stdin.encoding" is reflected for reading

Would be helpful to include why the test is limited to only linux and mac,

> "expect" command in Windows/Cygwin does not work as expected. Ignoring tests on Windows.

test/jdk/java/io/Console/StdinEncodingTest.java line 51:

> 49:         // check "expect" command availability
> 50:         var expect = Paths.get("/usr/bin/expect");
> 51:         if (!Files.exists(expect) || !Files.isExecutable(expect)) {

Could use `Assumptions.assumeTrue` here. Condition becomes more readable as: `Files.exists(expect) && Files.isExecutable(expect)`

test/jdk/java/io/Console/StdinEncodingTest.java line 56:

> 54: 
> 55:         // invoking "expect" command
> 56:         var testSrc = System.getProperty("test.src", ".");

The test already imports the JDK test lib, can we just replace this and the below ocurrences with `jdk.test.lib.Utils.TEST_SRC/JDK/CLASSES` directly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099438513
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099441523
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099447047
PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099443105

From jlahoda at openjdk.org  Wed May 21 07:05:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 May 2025 07:05:08 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v2]
In-Reply-To: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
Message-ID: <wDLBmJc_QnIhNsLomEkql6P1S2f7pjO1TLCvoxXKK30=.e887e08b-cdb1-49d8-94a1-04ed32eb4626@github.com>

> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
> 
> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
> 
> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
> 
> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.

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

  Must run on othervm

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25328/files
  - new: https://git.openjdk.org/jdk/pull/25328/files/759554f6..9d32c791

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

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

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

From jlahoda at openjdk.org  Wed May 21 07:23:07 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 21 May 2025 07:23:07 GMT
Subject: RFR: 8347050: Console.readLine() drops '\' when reading through
 JLine [v2]
In-Reply-To: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
References: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
Message-ID: <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>

> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().
> 
> This PR proposes to disable the history expansion.

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

  Fixing test on Windows.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25326/files
  - new: https://git.openjdk.org/jdk/pull/25326/files/fbf17434..392cede8

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

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

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

From vyazici at openjdk.org  Wed May 21 08:23:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 08:23:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
 <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
 <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>
Message-ID: <RiE9-8g0F1QOLT3xhcxUIWC6CR_TcisqFwPX9omahWM=.f39c6e44-8378-4ed6-b0b9-5a5aa252cded@github.com>

On Tue, 20 May 2025 22:04:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> All `FileDescriptor.in` encounters in `jdk.internal.org.jline.terminal` that might need attention:
>> 
>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/DumbTerminalProvider.java
>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecPty.java
>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/FfmTerminalProvider.java
>
> JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR

Created jline/jline3#1282.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099671435

From vyazici at openjdk.org  Wed May 21 08:32:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 08:32:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
Message-ID: <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>

On Tue, 20 May 2025 22:04:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/io/Console/StdinEncodingTest.java line 46:
>> 
>>> 44:  * @run junit StdinEncodingTest
>>> 45:  */
>>> 46: public class StdinEncodingTest {
>> 
>> AFAICT, there is no similar test (e.g., one using a mock `CharsetProvider`) for `stdout.encoding`. Will it be addressed by another ticket? Shall we consider adding a similar `StdoutEncodingTest` too? (Not necessarily in this PR.)
>
> `stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java`

Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none<sup>1</sup> that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too.

For the record, AFAICT, there are no tests for `stderr.encoding`.

<sup>1</sup> There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2099692717

From asotona at openjdk.org  Wed May 21 11:12:59 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 May 2025 11:12:59 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v2]
In-Reply-To: <wDLBmJc_QnIhNsLomEkql6P1S2f7pjO1TLCvoxXKK30=.e887e08b-cdb1-49d8-94a1-04ed32eb4626@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
 <wDLBmJc_QnIhNsLomEkql6P1S2f7pjO1TLCvoxXKK30=.e887e08b-cdb1-49d8-94a1-04ed32eb4626@github.com>
Message-ID: <LqyoG1KYcH72A1CaX6AhwJEsFQn6N1HCcRCWMBkj3TE=.048473f5-ab04-48d8-9686-969e0735040e@github.com>

On Wed, 21 May 2025 07:05:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
>> 
>> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
>> 
>> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
>> 
>> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Must run on othervm

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25328#pullrequestreview-2857282748

From naoto at openjdk.org  Wed May 21 16:50:12 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:50:12 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <euSlCn1VAYZ-bNi1jl0jFA8AXrVyhMSD1AyZSwWHmds=.9e874290-6358-4b91-8253-57f9561e7b77@github.com>

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

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

  Reflecting further comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25271/files
  - new: https://git.openjdk.org/jdk/pull/25271/files/ec420654..dd370768

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

  Stats: 22 lines in 2 files changed: 9 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25271/head:pull/25271

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

From naoto at openjdk.org  Wed May 21 16:57:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:57:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
 <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
Message-ID: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>

On Wed, 21 May 2025 06:12:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/io/Console.java line 67:
> 
>> 65:  * stdout.encoding}, in which case read operations use the {@code Charset}
>> 66:  * designated by {@code stdin.encoding}.
>> 67:  * <p>
> 
> `Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well.

Good point. Brought the same wording to the `charset()` method description for further clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100752794

From naoto at openjdk.org  Wed May 21 16:57:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:57:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <RiE9-8g0F1QOLT3xhcxUIWC6CR_TcisqFwPX9omahWM=.f39c6e44-8378-4ed6-b0b9-5a5aa252cded@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
 <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
 <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>
 <RiE9-8g0F1QOLT3xhcxUIWC6CR_TcisqFwPX9omahWM=.f39c6e44-8378-4ed6-b0b9-5a5aa252cded@github.com>
Message-ID: <UgD8f9t5Y-SxmsFcK0oSUWk7hIzdnysuEkZb5lSWgts=.b873bc23-dcd6-4cae-b602-be9cbdcbeed4@github.com>

On Wed, 21 May 2025 08:20:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> JLine is a 3rd party library. It would be desirable that they change their implementation to separately handle in/out in their terminal, but that is out of scope of this PR
>
> Created jline/jline3#1282.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100753459

From naoto at openjdk.org  Wed May 21 16:57:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:57:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
 <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
Message-ID: <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>

On Wed, 21 May 2025 08:30:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `stdout.encoding` validity is tested through the public `charset()` mehtod, which is in `CharsetTest.java`
>
> Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none<sup>1</sup> that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too.
> 
> For the record, AFAICT, there are no tests for `stderr.encoding`.
> 
> <sup>1</sup> There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`.

Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100762324

From naoto at openjdk.org  Wed May 21 16:57:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 16:57:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
 <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
 <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>
Message-ID: <p95EYb_nEBCfPpj5uTtE7HhrF0txSRLcQrULKYq1nwY=.90bf3699-fc29-44c8-ab42-a580cf454b30@github.com>

On Wed, 21 May 2025 16:53:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Indeed there *are* `stdout.encoding` tests in `test/jdk/java/io/Console`, yet none<sup>1</sup> that thoroughly tests them with `expect` and a dedicated (mock) `CharsetProvider` as you did here. FWIW, I really liked your new test using a mock `CharsetProvider` in combination with `expect`, hence my question for doing same for stdout and stderr too.
>> 
>> For the record, AFAICT, there are no tests for `stderr.encoding`.
>> 
>> <sup>1</sup> There is `script.exp`, but it tests `sun.stdout.encoding`, not `stdout.encoding`.
>
> Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input).

> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding.

It is addressed in this PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100763095

From jlu at openjdk.org  Wed May 21 18:09:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 21 May 2025 18:09:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v3]
In-Reply-To: <p95EYb_nEBCfPpj5uTtE7HhrF0txSRLcQrULKYq1nwY=.90bf3699-fc29-44c8-ab42-a580cf454b30@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
 <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
 <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>
 <p95EYb_nEBCfPpj5uTtE7HhrF0txSRLcQrULKYq1nwY=.90bf3699-fc29-44c8-ab42-a580cf454b30@github.com>
Message-ID: <myqXl51mHVhM6TjDOqMvGhCijJ5FwL3EEvk0krR6kOg=.881d941b-e2c2-46b2-8d9d-e5b2034879da@github.com>

On Wed, 21 May 2025 16:54:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Actually providing mock charset was a workaround of not having public method for getting the input encoding. I think it would be an overkill to introduce a new public method because it will not be used much, as most cases are suffice with the existing one (Console is used for interactive user enviornment, and I don't believe users would like to see different characters displayed for the input).
>
>> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding.
> 
> It is addressed in this PR

I think the JBS bug ID needs to be added to `CharsetTest.java` as well then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2100890130

From naoto at openjdk.org  Wed May 21 19:29:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 19:29:08 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v4]
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <kPGBTgP8cygkC-ufTlutlYYiAJ40KzRY57OGJxCu4j0=.ed8a0e9e-78b6-4bf4-8d66-4a60459d5e56@github.com>

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

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

  CharsetTest clean-up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25271/files
  - new: https://git.openjdk.org/jdk/pull/25271/files/dd370768..ce1c8035

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

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

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

From naoto at openjdk.org  Wed May 21 19:29:08 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 19:29:08 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v4]
In-Reply-To: <myqXl51mHVhM6TjDOqMvGhCijJ5FwL3EEvk0krR6kOg=.881d941b-e2c2-46b2-8d9d-e5b2034879da@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <8pTGTOHzyb9inoRKofkvU72-pQ--mf5BO81BFOgUbZs=.792d2e31-eaba-49b9-97a9-132d4bd81202@github.com>
 <8oTu0L0kqUfUTZ9kR8z8wPZi7WzY1Oz0gyf1U056rY4=.ca830d29-29f3-4692-ada5-beb5bd750c7e@github.com>
 <Frh347wHPLN6iVS4uGojdUBdbnP3Ulx15keIvh7nzyM=.9399e47b-9511-4f61-b451-9e19ac9b4e19@github.com>
 <p95EYb_nEBCfPpj5uTtE7HhrF0txSRLcQrULKYq1nwY=.90bf3699-fc29-44c8-ab42-a580cf454b30@github.com>
 <myqXl51mHVhM6TjDOqMvGhCijJ5FwL3EEvk0krR6kOg=.881d941b-e2c2-46b2-8d9d-e5b2034879da@github.com>
Message-ID: <fY_GgUx8bTJEM9r77v1TA-xViMXglNIUGpf-RIuVDAU=.a5e7ce8c-4b53-4ac4-9261-f8d56025ed02@github.com>

On Wed, 21 May 2025 18:07:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

>>> There is script.exp, but it tests sun.stdout.encoding, not stdout.encoding.
>> 
>> It is addressed in this PR
>
> I think the JBS bug ID needs to be added to `CharsetTest.java` as well then.

Bugid added to the test. Additionally replaced testsrc/jdk/classes with Utils ones

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2101014981

From vyazici at openjdk.org  Wed May 21 21:02:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 21 May 2025 21:02:04 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
Message-ID: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>

There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.

### Fixing strategy

* Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
* Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
* Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.

@naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.

### Scanning strategy

The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:


# Perl is used for multi-line matching
find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
git grep -H 'FileDescriptor.in' "*.java"


All calls to `InputStreamReader::new` and `Scanner::new` are checked too.

### Problems encountered

1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:

    ```
    DOMImplementationRegistry 
    InputRC 
    ListingErrorHandler 
    PandocFilter 
    ```
2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

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

Commit messages:
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

Changes: https://git.openjdk.org/jdk/pull/25368/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356893
  Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod
  Patch: https://git.openjdk.org/jdk/pull/25368.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368

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

From rriggs at openjdk.org  Wed May 21 21:39:53 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 May 2025 21:39:53 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

There too many changes in too many different areas to be in a single PR.
Please break it down by review areas.  Client, core libs, tools, etc.

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

PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030

From naoto at openjdk.org  Wed May 21 22:18:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 21 May 2025 22:18:51 GMT
Subject: RFR: 8347050: Console.readLine() drops '\' when reading through
 JLine [v2]
In-Reply-To: <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>
References: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
 <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>
Message-ID: <q8GmAfX4zAXmQ3rJVrOt5zfyxSh3kymt_84xnwXTEzQ=.107d9a11-f434-4d0e-ac65-4a08bb0305cf@github.com>

On Wed, 21 May 2025 07:23:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().
>> 
>> This PR proposes to disable the history expansion.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test on Windows.

Looks fine

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25326#pullrequestreview-2859258534

From alanb at openjdk.org  Thu May 22 05:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 05:54:52 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <wrtUfsbfcWNXz5eMaykcIbLOPC5019cvCsig_cLn7L4=.bd0dab1a-ad1e-465c-852b-8fb66d81f401@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

javax.swing.text.DefaultEditorKit.read(InputStream ...)  is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`.  From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753

From jlahoda at openjdk.org  Thu May 22 06:01:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 May 2025 06:01:57 GMT
Subject: RFR: 8347050: Console.readLine() drops '\' when reading through
 JLine [v2]
In-Reply-To: <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>
References: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
 <UwoOmfmFLX4yoa_KFHaRf9ox5oPzEROA_g_3RQLrIkw=.6b6573c1-05a4-4235-a7e1-fb57fc9605fa@github.com>
Message-ID: <TNlyO937OLbSHascDrrs9L82a-iqgtYvi-hgJakJg20=.367725f1-35eb-43a5-92ce-c96c7a4e0cdf@github.com>

On Wed, 21 May 2025 07:23:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().
>> 
>> This PR proposes to disable the history expansion.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test on Windows.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/25326#issuecomment-2900008739

From jlahoda at openjdk.org  Thu May 22 06:01:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 May 2025 06:01:58 GMT
Subject: Integrated: 8347050: Console.readLine() drops '\' when reading through
 JLine
In-Reply-To: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
References: <CrRA1pKBHMYHwGSTVCA4j_TTDsl56xMZ4jG_cd-KBhg=.97ee6b8b-06db-4831-ab6e-a15242df941b@github.com>
Message-ID: <9Zsfwz2gsl592Z9ziQiiStxWdPf582vrXsSO1TBQVbI=.82f0c2e4-3fd6-4de4-bf56-94f4bdbad112@github.com>

On Tue, 20 May 2025 13:07:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JLine can do history expansion, and interpret escapes, when returning a value. That is not desirable when using JLine as a backend for Console.readLine().
> 
> This PR proposes to disable the history expansion.

This pull request has now been integrated.

Changeset: 061b5cc6
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/061b5cc6b9939e182f3b2063ad86d042e35f0a91
Stats:     19 lines in 2 files changed: 17 ins; 0 del; 2 mod

8347050: Console.readLine() drops '\' when reading through JLine

Reviewed-by: naoto

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

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

From vyazici at openjdk.org  Thu May 22 07:59:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:09 GMT
Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
 <h1r8vY73RNYPmo58IlsyLRRdsji4zlhxTaaSZiM8434=.8a644894-d0e6-4fb6-8650-2432bc738341@github.com>
Message-ID: <JR9YcwtR6e9rtwHNRjzrc_f3vDzGlX5P7HbsynNMOmQ=.58dcd998-ff73-4547-b619-1ba8fa12bd7d@github.com>

On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
>> 
>> ### Fixing strategy
>> 
>> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
>> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
>> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
>> 
>> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
>> 
>> ### Scanning strategy
>> 
>> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
>> 
>> 
>> # Perl is used for multi-line matching
>> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
>> git grep -H 'FileDescriptor.in' "*.java"
>> 
>> 
>> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
>> 
>> ### Problems encountered
>> 
>> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
>> 
>>     ```
>>     DOMImplementationRegistry 
>>     InputRC 
>>     ListingErrorHandler 
>>     PandocFilter 
>>     ```
>> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property
>
> There too many changes in too many different areas to be in a single PR.
> Please break it down by review areas.  Client, core libs, tools, etc.

@RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will

1. withdraw this PR,
2. convert certain changes to spec clarifications,
3. and break it down to multiple PRs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422

From vyazici at openjdk.org  Thu May 22 07:59:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 07:59:10 GMT
Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner
In-Reply-To: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
References: <zUY_JnCeV8WBNrslGu4i4KYk4k1Rg0WbfO0WBPqjFwE=.19a8dc0b-2ea0-4db4-870d-8309c84619ed@github.com>
Message-ID: <cRfyJRr23DS3mw4U7XMBE6rBHXIWxlQiEcNpKG-wZBw=.6a7bcbb9-9cb6-45dc-8ce6-40fefbd328ff@github.com>

On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property.
> 
> ### Fixing strategy
> 
> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed.
> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed.
> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done.
> 
> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too.
> 
> ### Scanning strategy
> 
> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places:
> 
> 
> # Perl is used for multi-line matching
> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print
> git grep -H 'FileDescriptor.in' "*.java"
> 
> 
> All calls to `InputStreamReader::new` and `Scanner::new` are checked too.
> 
> ### Problems encountered
> 
> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes:
> 
>     ```
>     DOMImplementationRegistry 
>     InputRC 
>     ListingErrorHandler 
>     PandocFilter 
>     ```
> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property

This pull request has been closed without being integrated.

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

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

From vyazici at openjdk.org  Thu May 22 08:05:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 22 May 2025 08:05:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v4]
In-Reply-To: <kPGBTgP8cygkC-ufTlutlYYiAJ40KzRY57OGJxCu4j0=.ed8a0e9e-78b6-4bf4-8d66-4a60459d5e56@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <kPGBTgP8cygkC-ufTlutlYYiAJ40KzRY57OGJxCu4j0=.ed8a0e9e-78b6-4bf4-8d66-4a60459d5e56@github.com>
Message-ID: <cQELsC-0J1TuA_LuExhAZQ7mVm5wGTxr3Cv4xSaFBww=.58b8ea3f-8a12-430e-853c-95535d12bbc0@github.com>

On Wed, 21 May 2025 19:29:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CharsetTest clean-up

Marked as reviewed by vyazici (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2860206112

From jlahoda at openjdk.org  Thu May 22 12:04:12 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 May 2025 12:04:12 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v3]
In-Reply-To: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
Message-ID: <YqkfnDfo4YUgkWr4L-m4jq6GZs9Gp7uF1GbwNqoDyrM=.3c3a723f-92a7-4df1-a77c-dd42c17a53c9@github.com>

> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
> 
> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
> 
> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
> 
> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.

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

  Use stdin.encoding to read from System.in.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25328/files
  - new: https://git.openjdk.org/jdk/pull/25328/files/9d32c791..864a9dca

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

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

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

From asotona at openjdk.org  Thu May 22 13:25:01 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 22 May 2025 13:25:01 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v3]
In-Reply-To: <YqkfnDfo4YUgkWr4L-m4jq6GZs9Gp7uF1GbwNqoDyrM=.3c3a723f-92a7-4df1-a77c-dd42c17a53c9@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
 <YqkfnDfo4YUgkWr4L-m4jq6GZs9Gp7uF1GbwNqoDyrM=.3c3a723f-92a7-4df1-a77c-dd42c17a53c9@github.com>
Message-ID: <36sQff2qCnDC1QR7N6XD98VuHQ7iM5xDnRsOaKQ1YJU=.bb375483-5c9c-42be-89bf-af2f2d38fd32@github.com>

On Thu, 22 May 2025 12:04:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
>> 
>> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
>> 
>> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
>> 
>> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stdin.encoding to read from System.in.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25328#pullrequestreview-2861208781

From cstein at openjdk.org  Thu May 22 13:25:01 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 22 May 2025 13:25:01 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v3]
In-Reply-To: <YqkfnDfo4YUgkWr4L-m4jq6GZs9Gp7uF1GbwNqoDyrM=.3c3a723f-92a7-4df1-a77c-dd42c17a53c9@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
 <YqkfnDfo4YUgkWr4L-m4jq6GZs9Gp7uF1GbwNqoDyrM=.3c3a723f-92a7-4df1-a77c-dd42c17a53c9@github.com>
Message-ID: <dLnkQ-Ziv6OZu84WRQCrSygmCZR877BXYjBnCGjwGNc=.8a033476-bcf8-4b5f-9d9f-3c68dc2e024b@github.com>

On Thu, 22 May 2025 12:04:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
>> 
>> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
>> 
>> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
>> 
>> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stdin.encoding to read from System.in.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25328#pullrequestreview-2861217383

From jlahoda at openjdk.org  Thu May 22 14:06:41 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 22 May 2025 14:06:41 GMT
Subject: RFR: 8353581: Support for `import module` in JShell's code
 completion [v2]
In-Reply-To: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
References: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
Message-ID: <Bx0uf8BEG0UHA_N6Y4_KheQH2aJmTx1VZe2DDwL1MOk=.ccf089e0-0e24-4b4b-9c59-0a6e4b88a79e@github.com>

> Adding support for `import module ` to JShell's code completion.

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

 - Merge branch 'master' into JDK-8353581
 - Merge branch 'master' into JDK-8353581
 - Fixing typo in test.
 - 8353581: Support for `import module` in JShell's code completion

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

Changes: https://git.openjdk.org/jdk/pull/24442/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24442&range=01
  Stats: 96 lines in 2 files changed: 74 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/24442.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24442/head:pull/24442

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

From smarks at openjdk.org  Thu May 22 16:18:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 May 2025 16:18:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
 <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
 <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>
Message-ID: <UQT--71wmu1YGNVS6pc9KgdWFh209uGDpwb7GRkEp9w=.06799f2c-72f1-4919-8f12-5bce814e60d4@github.com>

On Wed, 21 May 2025 16:48:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 67:
>> 
>>> 65:  * stdout.encoding}, in which case read operations use the {@code Charset}
>>> 66:  * designated by {@code stdin.encoding}.
>>> 67:  * <p>
>> 
>> `Console.charset()` states "The returned charset is used for interpreting the input and output source (e.g., keyboard and/or display) specified by the host environment or user, which defaults to the one based on stdout.encoding." If _stdin.encoding_ is set otherwise, this is no longer true, so I think this method may need a wording update as well.
>
> Good point. Brought the same wording to the `charset()` method description for further clarification.

I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method.

I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2102946359

From alanb at openjdk.org  Thu May 22 16:42:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 May 2025 16:42:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <UQT--71wmu1YGNVS6pc9KgdWFh209uGDpwb7GRkEp9w=.06799f2c-72f1-4919-8f12-5bce814e60d4@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
 <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
 <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>
 <UQT--71wmu1YGNVS6pc9KgdWFh209uGDpwb7GRkEp9w=.06799f2c-72f1-4919-8f12-5bce814e60d4@github.com>
Message-ID: <ZE50hIJllKprRDuiyPyKjOFxIjTRV2xkQmPnuP_6400=.799194ca-f7fc-4184-97af-d10b5f490df1@github.com>

On Thu, 22 May 2025 16:15:56 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Good point. Brought the same wording to the `charset()` method description for further clarification.
>
> I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method.
> 
> I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method.

I think I agree with Stuart and it would be better to say that stdin.encoding is used for reading, and stdout.encoding for writing. They are usually the same but if they differ then Console will return the charset for output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2102987344

From naoto at openjdk.org  Thu May 22 17:46:33 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 May 2025 17:46:33 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

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

  Reflects wording change suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25271/files
  - new: https://git.openjdk.org/jdk/pull/25271/files/ce1c8035..75fa0a89

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

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

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

From naoto at openjdk.org  Thu May 22 17:48:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 May 2025 17:48:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v2]
In-Reply-To: <ZE50hIJllKprRDuiyPyKjOFxIjTRV2xkQmPnuP_6400=.799194ca-f7fc-4184-97af-d10b5f490df1@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <lErNIJyBSEaDtbZk91B6GQtqHc0o2qqGOaI-MH0r5ns=.404cffc7-5422-4b1d-b081-48bb8b9cf67a@github.com>
 <fl9VCx915VdNP3Bk-y4znN3OUM7_sfRJc5XMBHKf0Sk=.19862ac2-2908-424b-afd1-7939b9c0f79e@github.com>
 <54Ipy5980SJ3mqt5isPw1n4TNQnO7hH7DOlgLg3TSDI=.62f6bb57-278f-40b3-88d2-9f9a8a2031bb@github.com>
 <UQT--71wmu1YGNVS6pc9KgdWFh209uGDpwb7GRkEp9w=.06799f2c-72f1-4919-8f12-5bce814e60d4@github.com>
 <ZE50hIJllKprRDuiyPyKjOFxIjTRV2xkQmPnuP_6400=.799194ca-f7fc-4184-97af-d10b5f490df1@github.com>
Message-ID: <b__yTF1CV-NkG3fNul31WWVHpEcYqnk9BxraclK7DeA=.496bf1ab-b4db-470e-b8ee-2982c2a6af4e@github.com>

On Thu, 22 May 2025 16:39:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I'm confused by the actual behavior here. What might be helpful is to divide the discussion between a) what charsets get used for input and output, and b) the return value of the `charset()` method.
>> 
>> I'm not entirely sure, but since `stdin.encoding` and `stdout.encoding` are always set to something -- whether it comes from the platform or the command line -- won't Console just use `stdin.encoding` for input and `stdout.encoding` for output? If this is true, maybe just say this instead of deferring to the `charset()` method.
>
> I think I agree with Stuart and it would be better to say that stdin.encoding is used for reading, and stdout.encoding for writing. They are usually the same but if they differ then Console will return the charset for output.

Thanks. I reworded the descriptions of the class and `charset()` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2103101604

From liach at openjdk.org  Thu May 22 18:29:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 18:29:51 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v3]
In-Reply-To: <YqkfnDfo4YUgkWr4L-m4jq6GZs9Gp7uF1GbwNqoDyrM=.3c3a723f-92a7-4df1-a77c-dd42c17a53c9@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
 <YqkfnDfo4YUgkWr4L-m4jq6GZs9Gp7uF1GbwNqoDyrM=.3c3a723f-92a7-4df1-a77c-dd42c17a53c9@github.com>
Message-ID: <5dBV79aF-9aYgRr2AHzu17-PM3O8Iob94heHrIQ2RQw=.8e4d19f3-b31d-496e-b22e-9ebc09cb02bb@github.com>

On Thu, 22 May 2025 12:04:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
>> 
>> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
>> 
>> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
>> 
>> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stdin.encoding to read from System.in.

src/jdk.jshell/share/classes/jdk/jshell/execution/JdiDefaultExecutionControl.java line 116:

> 114:             FORWARD_SYSTEM_PROPERTIES.forEach(
> 115:                     prop -> augmentedremoteVMOptions.add("-D" + prop + "=" +
> 116:                                                          System.getProperty(prop)));

Should we add a comment that these properties are always present?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25328#discussion_r2103171492

From jlu at openjdk.org  Thu May 22 20:36:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 20:36:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <SoZ3agUUej7ri8CRCDEkbiB-wrZXhXp00yCqqQbumtU=.1035fe41-4f62-493a-aa15-fba1e7b0ba78@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

New wording is straightforward and looks good to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2862507794

From smarks at openjdk.org  Fri May 23 03:49:51 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 23 May 2025 03:49:51 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

I may be overthinking this, but let me just toss this out there to get people's opinions.

This changes the API of `jdk.internal.io.JdkConsoleProvider`. OK, this is an internal interface, so strictly speaking we can change it at will. But... do the IDEs use this to interface to implement their in-IDE terminal emulator? I'm not sure; maybe we should ask @lahodaj .

Well, the IDEs can probably easily adapt based on the JDK version. Or, if we want to be nice, we can leave the two-arg `console` method in place and have a default implementation for the three-arg `console` method that just calls the two-arg method with one of the charsets. Might not be worth it though.

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

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2903161425

From jlahoda at openjdk.org  Fri May 23 06:17:08 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 23 May 2025 06:17:08 GMT
Subject: RFR: 8353581: Support for `import module` in JShell's code
 completion [v3]
In-Reply-To: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
References: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
Message-ID: <iGETQhwek2wOoo0RbafhXA1wMVDzpeQlXUIorEk_Aik=.3ccb2bbc-fe03-457a-8e25-e6b2fad4beab@github.com>

> Adding support for `import module ` to JShell's code completion.

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

  Adjusting behavior for cases like import module ja<tab>;

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24442/files
  - new: https://git.openjdk.org/jdk/pull/24442/files/53dd46b7..a5ba85a8

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

  Stats: 51 lines in 2 files changed: 8 ins; 29 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24442.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24442/head:pull/24442

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

From liach at openjdk.org  Fri May 23 09:06:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 May 2025 09:06:52 GMT
Subject: RFR: 8355323: JShell LocalExecutionControl should add stopCheck()
 at method entry [v3]
In-Reply-To: <k5FiiN44Z25kiKHVO6ISB0jIt13GoMyIbUZJ5AvToog=.c487a3e5-f1e3-491b-be67-df7caa367b0c@github.com>
References: <-p1nWehmTqoGgji9x6_mzVB5xTvAo-tD8arZsLukQT0=.0123c91e-4346-4042-a9a4-9b54606a58de@github.com>
 <k5FiiN44Z25kiKHVO6ISB0jIt13GoMyIbUZJ5AvToog=.c487a3e5-f1e3-491b-be67-df7caa367b0c@github.com>
Message-ID: <tIeZp75cVI46teUmA8C0FUPXjrMLCTCX2xxD-Gllwrw=.918634bb-3976-4b90-bbce-90452592d02b@github.com>

On Fri, 25 Apr 2025 02:32:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR addresses [JDK-8355323](https://bugs.openjdk.org/browse/JDK-8355323), which inserts a "stop check" at the start of each method when JShell is running in local execution mode. This augments the existing stop checks that are added at each backward branch, which, while helpful, do not guarantee the snippet thread will notice a stop request in a bounded length of time, because a snippet could be executing some recursive method(s) that have no backward branches (an example is given in the new regression test). This fix closes that loophole.
>> 
>> Side notes:
>> * The existing `StopExecutionTest` unit test was split/refactored to create an `AbstractStopExecutionTest` superclass which could be reused by the new `LocalStopExecutionTest`.
>> * There are three disabled tests in `StopExecutionTest` that seem to be working now and maybe could be re-enabled.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrights.

@lahodaj Can you look at this?

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

PR Comment: https://git.openjdk.org/jdk/pull/24859#issuecomment-2903780574

From asotona at openjdk.org  Fri May 23 10:58:52 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 23 May 2025 10:58:52 GMT
Subject: RFR: 8353581: Support for `import module` in JShell's code
 completion [v3]
In-Reply-To: <iGETQhwek2wOoo0RbafhXA1wMVDzpeQlXUIorEk_Aik=.3ccb2bbc-fe03-457a-8e25-e6b2fad4beab@github.com>
References: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
 <iGETQhwek2wOoo0RbafhXA1wMVDzpeQlXUIorEk_Aik=.3ccb2bbc-fe03-457a-8e25-e6b2fad4beab@github.com>
Message-ID: <iq-gz4cYLKxhMKUN1Xa1QOsXnWlyNmRi1A_Yl4SEcUM=.741da522-7eed-49eb-b9dd-e9586d92b5ac@github.com>

On Fri, 23 May 2025 06:17:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adding support for `import module ` to JShell's code completion.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting behavior for cases like import module ja<tab>;

Works perfectly now.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24442#pullrequestreview-2864027288

From jlahoda at openjdk.org  Fri May 23 12:26:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 23 May 2025 12:26:52 GMT
Subject: RFR: 8355323: JShell LocalExecutionControl should add stopCheck()
 at method entry [v3]
In-Reply-To: <k5FiiN44Z25kiKHVO6ISB0jIt13GoMyIbUZJ5AvToog=.c487a3e5-f1e3-491b-be67-df7caa367b0c@github.com>
References: <-p1nWehmTqoGgji9x6_mzVB5xTvAo-tD8arZsLukQT0=.0123c91e-4346-4042-a9a4-9b54606a58de@github.com>
 <k5FiiN44Z25kiKHVO6ISB0jIt13GoMyIbUZJ5AvToog=.c487a3e5-f1e3-491b-be67-df7caa367b0c@github.com>
Message-ID: <gl00aVdpYwZoSofW3uauhlg1J2G8whseR9SH6DoQAys=.e4b16607-f0a2-4cad-b134-574405e3284d@github.com>

On Fri, 25 Apr 2025 02:32:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR addresses [JDK-8355323](https://bugs.openjdk.org/browse/JDK-8355323), which inserts a "stop check" at the start of each method when JShell is running in local execution mode. This augments the existing stop checks that are added at each backward branch, which, while helpful, do not guarantee the snippet thread will notice a stop request in a bounded length of time, because a snippet could be executing some recursive method(s) that have no backward branches (an example is given in the new regression test). This fix closes that loophole.
>> 
>> Side notes:
>> * The existing `StopExecutionTest` unit test was split/refactored to create an `AbstractStopExecutionTest` superclass which could be reused by the new `LocalStopExecutionTest`.
>> * There are three disabled tests in `StopExecutionTest` that seem to be working now and maybe could be re-enabled.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyrights.

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24859#pullrequestreview-2864235927

From acobbs at openjdk.org  Fri May 23 13:37:02 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 23 May 2025 13:37:02 GMT
Subject: RFR: 8355323: JShell LocalExecutionControl should add stopCheck()
 at method entry [v3]
In-Reply-To: <gl00aVdpYwZoSofW3uauhlg1J2G8whseR9SH6DoQAys=.e4b16607-f0a2-4cad-b134-574405e3284d@github.com>
References: <-p1nWehmTqoGgji9x6_mzVB5xTvAo-tD8arZsLukQT0=.0123c91e-4346-4042-a9a4-9b54606a58de@github.com>
 <k5FiiN44Z25kiKHVO6ISB0jIt13GoMyIbUZJ5AvToog=.c487a3e5-f1e3-491b-be67-df7caa367b0c@github.com>
 <gl00aVdpYwZoSofW3uauhlg1J2G8whseR9SH6DoQAys=.e4b16607-f0a2-4cad-b134-574405e3284d@github.com>
Message-ID: <DfR0iWDuykpfLRtyUP0eE0F6E8hgWjGT0HDJnGf1K18=.fe71f31d-7b47-43d7-8ef2-52fa82622d09@github.com>

On Fri, 23 May 2025 12:24:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyrights.
>
> Looks reasonable to me.

@lahodaj thanks for the review, much appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24859#issuecomment-2904444941

From acobbs at openjdk.org  Fri May 23 13:37:03 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 23 May 2025 13:37:03 GMT
Subject: Integrated: 8355323: JShell LocalExecutionControl should add
 stopCheck() at method entry
In-Reply-To: <-p1nWehmTqoGgji9x6_mzVB5xTvAo-tD8arZsLukQT0=.0123c91e-4346-4042-a9a4-9b54606a58de@github.com>
References: <-p1nWehmTqoGgji9x6_mzVB5xTvAo-tD8arZsLukQT0=.0123c91e-4346-4042-a9a4-9b54606a58de@github.com>
Message-ID: <5soRKNie7QajZ5YaBMUplwGGSVbTTvr3gMPz_7eoDYs=.cdf1f494-9984-429c-947c-98bb638dab27@github.com>

On Thu, 24 Apr 2025 20:35:28 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR addresses [JDK-8355323](https://bugs.openjdk.org/browse/JDK-8355323), which inserts a "stop check" at the start of each method when JShell is running in local execution mode. This augments the existing stop checks that are added at each backward branch, which, while helpful, do not guarantee the snippet thread will notice a stop request in a bounded length of time, because a snippet could be executing some recursive method(s) that have no backward branches (an example is given in the new regression test). This fix closes that loophole.
> 
> Side notes:
> * The existing `StopExecutionTest` unit test was split/refactored to create an `AbstractStopExecutionTest` superclass which could be reused by the new `LocalStopExecutionTest`.
> * There are three disabled tests in `StopExecutionTest` that seem to be working now and maybe could be re-enabled.

This pull request has now been integrated.

Changeset: d0402dda
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0402ddad72f8ac251d963d57cd6710d6aa655d1
Stats:     257 lines in 4 files changed: 199 ins; 54 del; 4 mod

8355323: JShell LocalExecutionControl should add stopCheck() at method entry

Reviewed-by: liach, jlahoda

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

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

From naoto at openjdk.org  Fri May 23 16:28:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 May 2025 16:28:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
 <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>
Message-ID: <EadaD3Jc9ldEB1m3p4jDElYAAldULkumK4c71RlUXTE=.c0dc165c-43c3-407e-9105-5ab082eea3b6@github.com>

On Fri, 23 May 2025 03:47:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> But... do the IDEs use this to interface to implement their in-IDE terminal emulator?

Can they even possibly do so?  `java.base`'s `module-info` exports `jdk.internal.io` only to `jdk.internal.le` and `jdk.jshell`, so I think no other modules can implement it and be loaded at runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905030550

From smarks at openjdk.org  Fri May 23 17:20:58 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 23 May 2025 17:20:58 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <EadaD3Jc9ldEB1m3p4jDElYAAldULkumK4c71RlUXTE=.c0dc165c-43c3-407e-9105-5ab082eea3b6@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
 <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>
 <EadaD3Jc9ldEB1m3p4jDElYAAldULkumK4c71RlUXTE=.c0dc165c-43c3-407e-9105-5ab082eea3b6@github.com>
Message-ID: <t6Og1IesTuCW7yIUpSKEOWlP1V_E3S11pP0jEJTY-nM=.6458ee3c-0da0-42b4-878c-96e585727379@github.com>

On Fri, 23 May 2025 16:26:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Can they even possibly do so?

Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and it can easily be invoked or modified to allow use of those modules. I took a quick look at NetBeans and didn't see any references to `jdk.internal.io` though, so maybe I'm off base in thinking that they might be using it. I did have the impression that at least one of the IDEs had its own console provider implementation but this is anecdotal and I don't have any evidence of this.

No need to worry about this now, then. Sorry for the distraction.

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

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905196982

From smarks at openjdk.org  Fri May 23 17:25:54 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 23 May 2025 17:25:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <3PAzs0ls7IGYZmW5m4VM-wIpr_vq080rwXCunwgwe78=.5a2669e4-201d-478d-9c0d-951770b315de@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

Marked as reviewed by smarks (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2865165348

From jlahoda at openjdk.org  Fri May 23 17:25:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 23 May 2025 17:25:54 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <t6Og1IesTuCW7yIUpSKEOWlP1V_E3S11pP0jEJTY-nM=.6458ee3c-0da0-42b4-878c-96e585727379@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
 <4zSAcMMCamSOEtcAWTJBtBa3jRLIdf3DdOOAtbETxgs=.78a7086b-2ac9-4351-a001-4ec8ed83479b@github.com>
 <EadaD3Jc9ldEB1m3p4jDElYAAldULkumK4c71RlUXTE=.c0dc165c-43c3-407e-9105-5ab082eea3b6@github.com>
 <t6Og1IesTuCW7yIUpSKEOWlP1V_E3S11pP0jEJTY-nM=.6458ee3c-0da0-42b4-878c-96e585727379@github.com>
Message-ID: <ucXKAz0dqGAQH94a-LFwGAXHQOpyAqgw9DXOeZTECGw=.05160ac7-dfd9-44b0-acb0-8e70319731dd@github.com>

On Fri, 23 May 2025 17:18:40 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> > Can they even possibly do so?
> 
> Sure, as far as I know, IntelliJ IDEA runs on its own version of the JDK, and it can easily be invoked or modified to allow use of those modules. I took a quick look at NetBeans and didn't see any references to `jdk.internal.io` though, so maybe I'm off base in thinking that they might be using it. I did have the impression that at least one of the IDEs had its own console provider implementation but this is anecdotal and I don't have any evidence of this.

FWIW, I am not aware about NetBeans using JdkConsoleProvider.

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

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905211226

From naoto at openjdk.org  Fri May 23 17:30:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 May 2025 17:30:52 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <EfgK6ACuxC_AgPZM2uN59XhWtcDBQm4nL1IKfcP4YUA=.ab538429-434b-4854-94bc-888c1a787c99@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

IntelliJ seems to be going with `-Djdk.console=jdk.internal.le` option, instead of hacking into the system: https://mastodon.online/@tagir_valeev/109981464706470933

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

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2905233081

From naoto at openjdk.org  Fri May 23 18:36:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 May 2025 18:36:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <UgD8f9t5Y-SxmsFcK0oSUWk7hIzdnysuEkZb5lSWgts=.b873bc23-dcd6-4cae-b602-be9cbdcbeed4@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <hPZPx0RnQBdl5Qk_qg_03NbVCUte6M9bDHDtJDWp0gk=.01806cbe-9d70-4de2-976e-3ddd0b474fac@github.com>
 <Pup4nswVBdebz4T4tOR33WuL7iedobsLXh-FjSh4e6E=.7eb43d7b-4c9a-490e-9a1f-168fee7bdf9b@github.com>
 <ogXKGEuLuPNjbiKf2n8GLsIAUAgCqs6alj69rYqGMDU=.c72dc1a5-dfa2-44dc-a808-81162dec14b6@github.com>
 <gjZaymAsEf2eto9WZwSgSOCBVCy4n_3-CYUaIrGDaKI=.a6168cc0-d6b9-4685-97d9-82eba329680b@github.com>
 <RiE9-8g0F1QOLT3xhcxUIWC6CR_TcisqFwPX9omahWM=.f39c6e44-8378-4ed6-b0b9-5a5aa252cded@github.com>
 <UgD8f9t5Y-SxmsFcK0oSUWk7hIzdnysuEkZb5lSWgts=.b873bc23-dcd6-4cae-b602-be9cbdcbeed4@github.com>
Message-ID: <TjVVwUxD3apJksa99fXng1GHA47JW2lNYqZ8OmFZvkU=.83b4856a-8f74-488d-b4bb-440e86b1c06a@github.com>

On Wed, 21 May 2025 16:48:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Created jline/jline3#1282.
>
> Thanks!

JLine seems to incorporate the stdin encoding already, which is quick!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25271#discussion_r2105219623

From jlahoda at openjdk.org  Mon May 26 04:43:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 26 May 2025 04:43:55 GMT
Subject: Integrated: 8353581: Support for `import module` in JShell's code
 completion
In-Reply-To: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
References: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
Message-ID: <HNYncVzTQNFdGcz-V_sZeVCD0o0_pWj7hL2PvG2_3zw=.5076ff3d-34c0-464f-a07d-f81811157087@github.com>

On Fri, 4 Apr 2025 09:08:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adding support for `import module ` to JShell's code completion.

This pull request has now been integrated.

Changeset: aac287eb
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aac287ebacbd982f3c17f5687ec2aff638a82a63
Stats:     74 lines in 2 files changed: 53 ins; 0 del; 21 mod

8353581: Support for `import module` in JShell's code completion

Reviewed-by: asotona

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

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

From alanb at openjdk.org  Mon May 26 07:22:49 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 May 2025 07:22:49 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <s4dKsfyuUa1cRaFNYJRe0hUrNQjppVQLLM80KYsGWhc=.b343fac6-9587-4313-b117-dbaf9fe6378b@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

Spec update and src changes looks good.  

I only skimmed through the test changes (not a detailed review) and they look reasonable. I assume you've done some "test repeat" jobs to ensure that any variance in the version of "expect" on test machines doesn't cause any issues.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25271#pullrequestreview-2867506507

From jlahoda at openjdk.org  Mon May 26 15:29:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 26 May 2025 15:29:09 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v4]
In-Reply-To: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
Message-ID: <lcZDX2DDGCuc1SLswzRvXcUV17pIWD7gEO9O1Gn6LAo=.36258fa5-1637-4664-9bce-fee402349477@github.com>

> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
> 
> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
> 
> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
> 
> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.

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

  Adding comment as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25328/files
  - new: https://git.openjdk.org/jdk/pull/25328/files/864a9dca..c7e7b0e6

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

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

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

From asotona at openjdk.org  Mon May 26 15:36:53 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 May 2025 15:36:53 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v4]
In-Reply-To: <lcZDX2DDGCuc1SLswzRvXcUV17pIWD7gEO9O1Gn6LAo=.36258fa5-1637-4664-9bce-fee402349477@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
 <lcZDX2DDGCuc1SLswzRvXcUV17pIWD7gEO9O1Gn6LAo=.36258fa5-1637-4664-9bce-fee402349477@github.com>
Message-ID: <QbWUHMyUSX_C7G6CyglIIjF-UP0cyqCgZmKDmWpzY94=.41e4a8ce-1357-426f-a02a-bdf9eaf3a812@github.com>

On Mon, 26 May 2025 15:29:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
>> 
>> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
>> 
>> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
>> 
>> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment as suggested.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25328#pullrequestreview-2868775978

From liach at openjdk.org  Mon May 26 15:36:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 May 2025 15:36:54 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v4]
In-Reply-To: <lcZDX2DDGCuc1SLswzRvXcUV17pIWD7gEO9O1Gn6LAo=.36258fa5-1637-4664-9bce-fee402349477@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
 <lcZDX2DDGCuc1SLswzRvXcUV17pIWD7gEO9O1Gn6LAo=.36258fa5-1637-4664-9bce-fee402349477@github.com>
Message-ID: <fPjBCMdTuN3rrJ7b7CFl6Sf-VgnoP7HjK0jZNkQ3fKI=.1f395ebc-59d5-4674-b7a3-ea20724ca2b9@github.com>

On Mon, 26 May 2025 15:29:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
>> 
>> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
>> 
>> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
>> 
>> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment as suggested.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25328#pullrequestreview-2868778046

From cstein at openjdk.org  Mon May 26 15:36:55 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 26 May 2025 15:36:55 GMT
Subject: RFR: 8356245: stdin.encoding and stdout.encoding in jshell don't
 respect console code pages [v4]
In-Reply-To: <lcZDX2DDGCuc1SLswzRvXcUV17pIWD7gEO9O1Gn6LAo=.36258fa5-1637-4664-9bce-fee402349477@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
 <lcZDX2DDGCuc1SLswzRvXcUV17pIWD7gEO9O1Gn6LAo=.36258fa5-1637-4664-9bce-fee402349477@github.com>
Message-ID: <ZqtHa0BMQRYIhn0XotWxFkk6CL-HKEU-kAib9xhZlzk=.0c5b17d4-e4dc-49b8-9dfd-a91603bf81e0@github.com>

On Mon, 26 May 2025 15:29:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
>> 
>> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
>> 
>> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
>> 
>> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding comment as suggested.

Marked as reviewed by cstein (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25328#pullrequestreview-2868780794

From jlahoda at openjdk.org  Tue May 27 09:51:58 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 May 2025 09:51:58 GMT
Subject: Integrated: 8356245: stdin.encoding and stdout.encoding in jshell
 don't respect console code pages
In-Reply-To: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
References: <ICV43KzgcUIGkBSIiUgeaLTiWDQaTZ0kaUQUt_VUJn4=.87943a68-1c5b-4832-b7e3-e6d61ef8116f@github.com>
Message-ID: <uwohBZdY41AWdvkGY2chgqKUWcdT8cOADQrUon1Hzos=.eced5d33-580c-4d43-93dd-27933811ecd4@github.com>

On Tue, 20 May 2025 13:28:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell, by default, uses two processes: the main one which compiles snippets, and a remote, that runs them.
> 
> The remote process is not connected to console, and hence its in/out/err encoding will be derived from the platform encoding, while the main process will use encoding derived from the console settings.
> 
> This PR proposes to pass the stdin/out/err encoding from the main process to the remote process. It also has to change the char->byte conversion for System.in to use the `stdin.encoding`, so that the remote process understands it.
> 
> The `InputUITest` requires explicitly setting encoding, as the tests sometimes run with the ASCII encoding, but use Unicode characters, and fail, as the ASCII encoding is not really followed by JShell now.

This pull request has now been integrated.

Changeset: 9c191cc0
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c191cc0fad4e2cd8ac021082acc494dc7503745
Stats:     34 lines in 3 files changed: 19 ins; 2 del; 13 mod

8356245: stdin.encoding and stdout.encoding in jshell don't respect console code pages

Reviewed-by: asotona, cstein, liach

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

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

From naoto at openjdk.org  Tue May 27 16:03:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:03:53 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <s4dKsfyuUa1cRaFNYJRe0hUrNQjppVQLLM80KYsGWhc=.b343fac6-9587-4313-b117-dbaf9fe6378b@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
 <s4dKsfyuUa1cRaFNYJRe0hUrNQjppVQLLM80KYsGWhc=.b343fac6-9587-4313-b117-dbaf9fe6378b@github.com>
Message-ID: <qTRaUStoqQ96XCdviWLKMhPpN4d4EjjVhTOIl-kktKM=.21f331ca-e8ad-484d-a570-f387e54dc308@github.com>

On Mon, 26 May 2025 07:18:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you've done some "test repeat" jobs to ensure that any variance in the version of "expect" on test machines doesn't cause any issues.

Actually I have not. Thanks for reminding. So I ran this through our internal CI on Linux x64, macOS x64, and macOS AArch64. Across 10 tasks (i.e., machines), each with 30 repetitions, that?s a total of 900 test runs?all completed without failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2913132945

From naoto at openjdk.org  Wed May 28 16:27:00 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 16:27:00 GMT
Subject: RFR: 8356985: Use "stdin.encoding" in Console's read*() methods
 [v5]
In-Reply-To: <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
 <dFUEM1LCJ5srEihv8HkQLQ-z2-1709Gq2nXgHDaYT8w=.47e3b759-67a3-4e74-af96-0e710728945c@github.com>
Message-ID: <o98nfuStWFzGnsYs_OWnUtKShbwt_umJhvLFOy8b2us=.af181d42-02bf-4faf-bbde-030337376418@github.com>

On Thu, 22 May 2025 17:46:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects wording change suggestions

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25271#issuecomment-2916925800

From naoto at openjdk.org  Wed May 28 16:27:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 16:27:02 GMT
Subject: Integrated: 8356985: Use "stdin.encoding" in Console's read*() methods
In-Reply-To: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
References: <ZnzCb39bMXQlNC2ELkiJlTuKIhy776Stng6j5txAaFE=.bb66f86d-618b-4e97-9f08-4e5a13e1f5c8@github.com>
Message-ID: <XG7OepWrg1ZJ-D3MrapN_1vqY2ja4cKYg0-pvsUKOK8=.f45e5c22-c5c6-4041-92b5-080c833bfcb7@github.com>

On Fri, 16 May 2025 18:11:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `java.io.Console` uses the charset specified by the `stdout.encoding` system property for both input and output. While this is generally sufficient, since Console is intended for interactive terminal use, some platforms allow different encodings to be configured for input and output. In such cases, using a single encoding may lead to incorrect behavior when reading from the terminal. To address this, the newly introduced system property, `stdin.encoding`, should be used specifically for input where appropriate.

This pull request has now been integrated.

Changeset: b2a61a99
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2a61a9972493d67d0f1a9f3f529c11e45838d5b
Stats:     301 lines in 11 files changed: 256 ins; 8 del; 37 mod

8356985: Use "stdin.encoding" in Console's read*() methods

Reviewed-by: jlu, smarks, alanb, vyazici

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

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

From vyazici at openjdk.org  Fri May 30 10:51:02 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 30 May 2025 10:51:02 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [build/tools]
Message-ID: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>

Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.

`stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to build and tools.

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

Commit messages:
 - Discard changes unrelated with build and tools
 - Revert superfluous changes
 - Revert changes to 3rd parties in `com/sun/org/apache`
 - Revert `PandocFilter` changes
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations

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

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