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