From acobbs at openjdk.org  Sat Mar  1 03:19:29 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 1 Mar 2025 03:19:29 GMT
Subject: RFR: 8350983: JShell LocalExecutionControl only needs stopCheck() on
 backward branches
Message-ID: <tA7keLk1KvwpYTzVqbn60HNzHNzEFs8Pi93vf7mW5h0=.905627b5-283c-47f6-a979-03208b70ef47@github.com>

JShell's `LocalExecutionControl` ensures a running eval thread can be stopped by `JShell.stop()` by inserting an invocation of `stopCheck()` at every branch point in the bytecode of loaded classfiles.

However, this same guarantee can be provided by invoking `stopCheck()` only at backward branches and not at forward branches. By doing this, the performance and size impact on the executing code can be reduced.

Fortunately the new ClassFile API makes this kind of modification easy ?

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

Commit messages:
 - Only invoke stopCheck() at backward branches.

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

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

From liach at openjdk.org  Mon Mar  3 04:44:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Mar 2025 04:44:58 GMT
Subject: RFR: 8350983: JShell LocalExecutionControl only needs stopCheck()
 on backward branches
In-Reply-To: <tA7keLk1KvwpYTzVqbn60HNzHNzEFs8Pi93vf7mW5h0=.905627b5-283c-47f6-a979-03208b70ef47@github.com>
References: <tA7keLk1KvwpYTzVqbn60HNzHNzEFs8Pi93vf7mW5h0=.905627b5-283c-47f6-a979-03208b70ef47@github.com>
Message-ID: <3WQrwD7oAUfWNmafs_CTU80DC-R5uAdwQeECdDrEx84=.29e2064e-3816-497c-940b-ecb0c0750ed7@github.com>

On Sat, 1 Mar 2025 03:14:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> JShell's `LocalExecutionControl` ensures a running eval thread can be stopped by `JShell.stop()` by inserting an invocation of `stopCheck()` at every branch point in the bytecode of loaded classfiles.
> 
> However, this same guarantee can be provided by invoking `stopCheck()` only at backward branches and not at forward branches. By doing this, the performance and size impact on the executing code can be reduced.
> 
> Fortunately the new ClassFile API makes this kind of modification easy ?

src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 102:

> 100:                                 return (cob, coe) -> {
> 101:                                     switch (coe) {
> 102:                                     case BranchInstruction branch:

Can we use switch with `->` instead of `:` to avoid the error-prone breaks?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23850#discussion_r1976864784

From acobbs at openjdk.org  Mon Mar  3 15:19:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 3 Mar 2025 15:19:22 GMT
Subject: RFR: 8350983: JShell LocalExecutionControl only needs stopCheck()
 on backward branches [v2]
In-Reply-To: <tA7keLk1KvwpYTzVqbn60HNzHNzEFs8Pi93vf7mW5h0=.905627b5-283c-47f6-a979-03208b70ef47@github.com>
References: <tA7keLk1KvwpYTzVqbn60HNzHNzEFs8Pi93vf7mW5h0=.905627b5-283c-47f6-a979-03208b70ef47@github.com>
Message-ID: <lu40ZUdMUm8ZzR0e5HbcKL78mqbFpHJeTM2fyThQkCY=.f62146b9-d01a-48ed-ba95-763bd42cf31e@github.com>

> JShell's `LocalExecutionControl` ensures a running eval thread can be stopped by `JShell.stop()` by inserting an invocation of `stopCheck()` at every branch point in the bytecode of loaded classfiles.
> 
> However, this same guarantee can be provided by invoking `stopCheck()` only at backward branches and not at forward branches. By doing this, the performance and size impact on the executing code can be reduced.
> 
> Fortunately the new ClassFile API makes this kind of modification easy ?

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Niceify using pattern matching switch with guard per review suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23850/files
  - new: https://git.openjdk.org/jdk/pull/23850/files/f0a3c816..30c5f1a3

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

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

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

From acobbs at openjdk.org  Mon Mar  3 15:19:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 3 Mar 2025 15:19:22 GMT
Subject: RFR: 8350983: JShell LocalExecutionControl only needs stopCheck()
 on backward branches [v2]
In-Reply-To: <3WQrwD7oAUfWNmafs_CTU80DC-R5uAdwQeECdDrEx84=.29e2064e-3816-497c-940b-ecb0c0750ed7@github.com>
References: <tA7keLk1KvwpYTzVqbn60HNzHNzEFs8Pi93vf7mW5h0=.905627b5-283c-47f6-a979-03208b70ef47@github.com>
 <3WQrwD7oAUfWNmafs_CTU80DC-R5uAdwQeECdDrEx84=.29e2064e-3816-497c-940b-ecb0c0750ed7@github.com>
Message-ID: <guCBOawlAUJlrI5F1phU87rczoMiTlPKVQUIkA7I8Ww=.1409b683-ba7a-4ff6-96e6-bf4d09760d2c@github.com>

On Mon, 3 Mar 2025 04:42:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Niceify using pattern matching switch with guard per review suggestion.
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java line 102:
> 
>> 100:                                 return (cob, coe) -> {
>> 101:                                     switch (coe) {
>> 102:                                     case BranchInstruction branch:
> 
> Can we use switch with `->` instead of `:` to avoid the error-prone breaks?

Hi Chen! Excellent suggestion, thanks. Updated in 30c5f1a3c8b.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23850#discussion_r1977699619

From jlahoda at openjdk.org  Tue Mar  4 11:31:46 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 4 Mar 2025 11:31:46 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import Declarations
Message-ID: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>

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

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

Commit messages:
 - Cleanup.
 - Cleanup.
 - Finalizing module imports.

Changes: https://git.openjdk.org/jdk/pull/23801/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344708
  Stats: 113 lines in 15 files changed: 9 ins; 71 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

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

From jlahoda at openjdk.org  Tue Mar  4 13:36:04 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 4 Mar 2025 13:36:04 GMT
Subject: RFR: 8350808: Small typos in JShell method SnippetEvent.toString()
In-Reply-To: <RPzAkvxulY21rWGNsBBPlE-G9k8QYkNS7Q7Mfj776-E=.73553f95-2d2a-4e9a-8b9f-3b65c7336f52@github.com>
References: <RPzAkvxulY21rWGNsBBPlE-G9k8QYkNS7Q7Mfj776-E=.73553f95-2d2a-4e9a-8b9f-3b65c7336f52@github.com>
Message-ID: <bfwKNpz69orWPm1HP0S9VNhhIwy-7aM_nQCpgNzbkk8=.c4f66994-6a41-414a-80f6-b52889348e73@github.com>

On Wed, 26 Feb 2025 19:43:18 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR which fixes three small typos in the method `SnippetEvent.toString()`.

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23809#pullrequestreview-2657505394

From jlahoda at openjdk.org  Tue Mar  4 13:38:33 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 4 Mar 2025 13:38:33 GMT
Subject: RFR: 8326333: jshell <TAB> completion on arrays does not work for
 clone()
Message-ID: <6vr7b1HY1QShm2vtekAK8wimIfJ62x3STwja43qj-q4=.4fde9f87-7be4-49b9-983e-b2d499cfc6a4@github.com>

8326333: jshell <TAB> completion on arrays does not work for clone()

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

Commit messages:
 - 8326333: jshell <TAB> completion on arrays does not work for clone()

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

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

From acobbs at openjdk.org  Tue Mar  4 15:49:57 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 4 Mar 2025 15:49:57 GMT
Subject: RFR: 8350808: Small typos in JShell method SnippetEvent.toString()
In-Reply-To: <RPzAkvxulY21rWGNsBBPlE-G9k8QYkNS7Q7Mfj776-E=.73553f95-2d2a-4e9a-8b9f-3b65c7336f52@github.com>
References: <RPzAkvxulY21rWGNsBBPlE-G9k8QYkNS7Q7Mfj776-E=.73553f95-2d2a-4e9a-8b9f-3b65c7336f52@github.com>
Message-ID: <VpQQoBuuDLAZC6ZZZqMGCrCV6sLK3bmDJeP51ggK7fo=.eb94b84e-0ef9-4264-96bf-858601a353b6@github.com>

On Wed, 26 Feb 2025 19:43:18 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR which fixes three small typos in the method `SnippetEvent.toString()`.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23809#issuecomment-2698088295

From vromero at openjdk.org  Tue Mar  4 19:23:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 4 Mar 2025 19:23:54 GMT
Subject: RFR: 8344708: Compiler Implementation of 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: <hPt0ZKToYxJsVA6S67vaM-HGGTFGkcXUZq9vV0u63aQ=.ccd34233-7e47-416c-802e-c58e9334acca@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

looks sensible

test/langtools/tools/javac/modules/EdgeCases.java line 1190:

> 1188: 
> 1189:         List<String> expected = List.of(
> 1190:                 "Test.java:2:8: compiler.err.feature.not.supported.in.source.plural: (compiler.misc.feature.module.imports), 24, 25",

isn't there a similar test above?

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2658747032
PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r1980096065

From acobbs at openjdk.org  Wed Mar  5 17:36:59 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 5 Mar 2025 17:36:59 GMT
Subject: Integrated: 8350808: Small typos in JShell method
 SnippetEvent.toString()
In-Reply-To: <RPzAkvxulY21rWGNsBBPlE-G9k8QYkNS7Q7Mfj776-E=.73553f95-2d2a-4e9a-8b9f-3b65c7336f52@github.com>
References: <RPzAkvxulY21rWGNsBBPlE-G9k8QYkNS7Q7Mfj776-E=.73553f95-2d2a-4e9a-8b9f-3b65c7336f52@github.com>
Message-ID: <2j5i12E6KvpTbtqz3Hvr33Y7Da-DKdHHuiAY0oyCqJk=.5ae67c4a-b88f-4f2c-9540-0476be6e4ffe@github.com>

On Wed, 26 Feb 2025 19:43:18 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR which fixes three small typos in the method `SnippetEvent.toString()`.

This pull request has now been integrated.

Changeset: 6012e8d2
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6012e8d2505af786bd4f17cf56b1e81a102485d4
Stats:     67 lines in 2 files changed: 63 ins; 0 del; 4 mod

8350808: Small typos in JShell method SnippetEvent.toString()

Reviewed-by: jlahoda

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

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

From liach at openjdk.org  Wed Mar  5 18:04:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 18:04:10 GMT
Subject: RFR: 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: <e73VA3yysfFD6f3HN497LQorC-9jEMi6X7PQtYOvDtE=.f2caf2da-a12f-45b1-8a8b-f3ba791a5a42@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.

test/langtools/jdk/jshell/LocalExecutionControlExceptionTest.java line 138:

> 136:             //run in a ThreadGroup which does not handle the uncaught exceptions, and let them
> 137:             //pass to the default uncaught handler for the test:
> 138:             var thread = new Thread(Thread.currentThread().getThreadGroup().getParent(), "test-group") {

Is there a reason we cannot use this for `outsideOfJShell` above so we don't need this aop thing?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12982#discussion_r1981909541

From liach at openjdk.org  Wed Mar  5 18:04:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 5 Mar 2025 18:04:55 GMT
Subject: RFR: 8326333: jshell <TAB> completion on arrays does not work for
 clone()
In-Reply-To: <6vr7b1HY1QShm2vtekAK8wimIfJ62x3STwja43qj-q4=.4fde9f87-7be4-49b9-983e-b2d499cfc6a4@github.com>
References: <6vr7b1HY1QShm2vtekAK8wimIfJ62x3STwja43qj-q4=.4fde9f87-7be4-49b9-983e-b2d499cfc6a4@github.com>
Message-ID: <h8dZRZEI78ESVySdLptJtol_P8di-Tg6DobqRZ14Gt0=.37f9f585-617c-42d3-9e0e-1118e91e9106@github.com>

On Tue, 4 Mar 2025 13:31:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8326333: jshell <TAB> completion on arrays does not work for clone()

The issue number should be 8350595.

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

PR Comment: https://git.openjdk.org/jdk/pull/23899#issuecomment-2701688364

From jpai at openjdk.org  Tue Mar 11 10:48:19 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Mar 2025 10:48:19 GMT
Subject: RFR: 8351639: Improve debuggability of
 test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java test
Message-ID: <JjGGclihwSIE0WMrNB4NL1Tmpx_eCNRVoR3gqqrOen8=.6c00e570-8145-4091-97af-7efb49cf8793@github.com>

Can I please get a review of this test-only change which proposes to improve the debuggability of `test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java` when it fails intermittently?

This test has failed a few times in the CI and as noted in the description of https://bugs.openjdk.org/browse/JDK-8351639, the failure happens when the test doesn't find the expected exception message in the `IllegalStateException` that gets thrown. When I initially filed that issue, I thought the (unexpected) exception message wasn't being printed. But turns out the `assertTrue(...)` call does indeed print the original exception message:

> Launching JShell execution engine threw: Failed remote listen: java.util.concurrent.ExecutionException: com.sun.jdi.connect.TransportTimeoutException: timeout waiting for connection @ com.sun.jdi.SocketListen (defaults: timeout=, port=, localAddress=) -- {timeout=timeout=8000, port=port=59547, localAddress=localAddress=}

Even so, I think the proposed change in this PR to rethrow the original exception and thus have the entire exception stacktrace available for analysis would be useful for any such failures in future.

The test continues to pass with this change.

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

Commit messages:
 - 8351639: Improve debuggability of test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java test

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

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

From jlahoda at openjdk.org  Tue Mar 11 13:20:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 11 Mar 2025 13:20:57 GMT
Subject: RFR: 8351639: Improve debuggability of
 test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java test
In-Reply-To: <JjGGclihwSIE0WMrNB4NL1Tmpx_eCNRVoR3gqqrOen8=.6c00e570-8145-4091-97af-7efb49cf8793@github.com>
References: <JjGGclihwSIE0WMrNB4NL1Tmpx_eCNRVoR3gqqrOen8=.6c00e570-8145-4091-97af-7efb49cf8793@github.com>
Message-ID: <2I8GK0csGqWPzlhKsXN4pvzI2_A-9NMhJsyDyXudYa8=.1f9299b6-7a25-4d0e-a29a-af62ba1812c8@github.com>

On Tue, 11 Mar 2025 10:43:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to improve the debuggability of `test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java` when it fails intermittently?
> 
> This test has failed a few times in the CI and as noted in the description of https://bugs.openjdk.org/browse/JDK-8351639, the failure happens when the test doesn't find the expected exception message in the `IllegalStateException` that gets thrown. When I initially filed that issue, I thought the (unexpected) exception message wasn't being printed. But turns out the `assertTrue(...)` call does indeed print the original exception message:
> 
>> Launching JShell execution engine threw: Failed remote listen: java.util.concurrent.ExecutionException: com.sun.jdi.connect.TransportTimeoutException: timeout waiting for connection @ com.sun.jdi.SocketListen (defaults: timeout=, port=, localAddress=) -- {timeout=timeout=8000, port=port=59547, localAddress=localAddress=}
> 
> Even so, I think the proposed change in this PR to rethrow the original exception and thus have the entire exception stacktrace available for analysis would be useful for any such failures in future.
> 
> The test continues to pass with this change.

Looks reasonable to me. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23978#pullrequestreview-2674494131

From jpai at openjdk.org  Wed Mar 12 06:59:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 06:59:56 GMT
Subject: RFR: 8351639: Improve debuggability of
 test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java test
In-Reply-To: <JjGGclihwSIE0WMrNB4NL1Tmpx_eCNRVoR3gqqrOen8=.6c00e570-8145-4091-97af-7efb49cf8793@github.com>
References: <JjGGclihwSIE0WMrNB4NL1Tmpx_eCNRVoR3gqqrOen8=.6c00e570-8145-4091-97af-7efb49cf8793@github.com>
Message-ID: <OmdKg9zwNCCZx7oycWBTv6Wulw5Ts_j7InNgcoaRLk8=.22167908-fdfc-4479-ad09-308843000ac2@github.com>

On Tue, 11 Mar 2025 10:43:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to improve the debuggability of `test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java` when it fails intermittently?
> 
> This test has failed a few times in the CI and as noted in the description of https://bugs.openjdk.org/browse/JDK-8351639, the failure happens when the test doesn't find the expected exception message in the `IllegalStateException` that gets thrown. When I initially filed that issue, I thought the (unexpected) exception message wasn't being printed. But turns out the `assertTrue(...)` call does indeed print the original exception message:
> 
>> Launching JShell execution engine threw: Failed remote listen: java.util.concurrent.ExecutionException: com.sun.jdi.connect.TransportTimeoutException: timeout waiting for connection @ com.sun.jdi.SocketListen (defaults: timeout=, port=, localAddress=) -- {timeout=timeout=8000, port=port=59547, localAddress=localAddress=}
> 
> Even so, I think the proposed change in this PR to rethrow the original exception and thus have the entire exception stacktrace available for analysis would be useful for any such failures in future.
> 
> The test continues to pass with this change.

Thank you Jan for the review. I ran these test with a test repeat of 50 in our CI and it hasn't regressed. I will go ahead and integrate this now. Hopefully when this fails the next time, we will have some additional details to investigate.

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

PR Comment: https://git.openjdk.org/jdk/pull/23978#issuecomment-2716733214

From jpai at openjdk.org  Wed Mar 12 06:59:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 12 Mar 2025 06:59:57 GMT
Subject: Integrated: 8351639: Improve debuggability of
 test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java test
In-Reply-To: <JjGGclihwSIE0WMrNB4NL1Tmpx_eCNRVoR3gqqrOen8=.6c00e570-8145-4091-97af-7efb49cf8793@github.com>
References: <JjGGclihwSIE0WMrNB4NL1Tmpx_eCNRVoR3gqqrOen8=.6c00e570-8145-4091-97af-7efb49cf8793@github.com>
Message-ID: <D6yiSm1HmKEZEVfwBJTq0l7g70FrYZp9SDijr3Kj2EA=.868356a6-f339-405f-84b4-cc4770e203e0@github.com>

On Tue, 11 Mar 2025 10:43:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to improve the debuggability of `test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java` when it fails intermittently?
> 
> This test has failed a few times in the CI and as noted in the description of https://bugs.openjdk.org/browse/JDK-8351639, the failure happens when the test doesn't find the expected exception message in the `IllegalStateException` that gets thrown. When I initially filed that issue, I thought the (unexpected) exception message wasn't being printed. But turns out the `assertTrue(...)` call does indeed print the original exception message:
> 
>> Launching JShell execution engine threw: Failed remote listen: java.util.concurrent.ExecutionException: com.sun.jdi.connect.TransportTimeoutException: timeout waiting for connection @ com.sun.jdi.SocketListen (defaults: timeout=, port=, localAddress=) -- {timeout=timeout=8000, port=port=59547, localAddress=localAddress=}
> 
> Even so, I think the proposed change in this PR to rethrow the original exception and thus have the entire exception stacktrace available for analysis would be useful for any such failures in future.
> 
> The test continues to pass with this change.

This pull request has now been integrated.

Changeset: 4412c079
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4412c079fccefbb235b22651206089f5bac47d18
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8351639: Improve debuggability of test/langtools/jdk/jshell/JdiHangingListenExecutionControlTest.java test

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.org  Mon Mar 17 13:55:05 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 17 Mar 2025 13:55:05 GMT
Subject: RFR: 8350749: Upgrade JLine to 3.29.0
Message-ID: <t209N9DjKqLh2TmxTUDZUq6tGg8fG4xlZk1276AADYE=.4ca06cb9-2d3d-4a6e-9708-dec5f474c16f@github.com>

This is an upgrade of JLine to JLine 3.29.0. It is basically applying a patch with changes between JLine 3.26.1 and JLine 3.29.0.

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

Commit messages:
 - 8350749: Upgrade JLine to 3.29.0

Changes: https://git.openjdk.org/jdk/pull/24080/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24080&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350749
  Stats: 178 lines in 18 files changed: 128 ins; 4 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/24080.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24080/head:pull/24080

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

From liach at openjdk.org  Mon Mar 17 21:45:14 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Mar 2025 21:45:14 GMT
Subject: RFR: 8350749: Upgrade JLine to 3.29.0
In-Reply-To: <t209N9DjKqLh2TmxTUDZUq6tGg8fG4xlZk1276AADYE=.4ca06cb9-2d3d-4a6e-9708-dec5f474c16f@github.com>
References: <t209N9DjKqLh2TmxTUDZUq6tGg8fG4xlZk1276AADYE=.4ca06cb9-2d3d-4a6e-9708-dec5f474c16f@github.com>
Message-ID: <bR8s3NwlmpeSv2Y2mM-PEAb4uutmqCb7rcJiPydbG-g=.09ed781a-6b3e-4c14-a56f-d3c244780f56@github.com>

On Mon, 17 Mar 2025 13:50:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an upgrade of JLine to JLine 3.29.0. It is basically applying a patch with changes between JLine 3.26.1 and JLine 3.29.0.

No dubious code changes.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24080#pullrequestreview-2692157368

From jlahoda at openjdk.org  Thu Mar 20 15:20:15 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Mar 2025 15:20:15 GMT
Subject: Integrated: 8350749: Upgrade JLine to 3.29.0
In-Reply-To: <t209N9DjKqLh2TmxTUDZUq6tGg8fG4xlZk1276AADYE=.4ca06cb9-2d3d-4a6e-9708-dec5f474c16f@github.com>
References: <t209N9DjKqLh2TmxTUDZUq6tGg8fG4xlZk1276AADYE=.4ca06cb9-2d3d-4a6e-9708-dec5f474c16f@github.com>
Message-ID: <2FuIOaO5JePeHAbXN9Qr5UEk3m2YeUaOV3nA0efHuEg=.5dffc567-4835-4fec-a957-b0ded19a8250@github.com>

On Mon, 17 Mar 2025 13:50:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an upgrade of JLine to JLine 3.29.0. It is basically applying a patch with changes between JLine 3.26.1 and JLine 3.29.0.

This pull request has now been integrated.

Changeset: 9a17a6ff
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a17a6ff0f7b53e9d87bf5db85399aabeb2582c8
Stats:     178 lines in 18 files changed: 128 ins; 4 del; 46 mod

8350749: Upgrade JLine to 3.29.0

Reviewed-by: liach

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

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

From jlahoda at openjdk.org  Wed Mar 26 08:28:15 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Mar 2025 08:28:15 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
Message-ID: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>

The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.

The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.

The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

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

Commit messages:
 - Removing trailing whitespace
 - 8352693: Use a simpler console reader instead of JLine for System.console()

Changes: https://git.openjdk.org/jdk/pull/24242/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24242&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352693
  Stats: 2502 lines in 22 files changed: 1872 ins; 600 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/24242.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24242/head:pull/24242

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

From alanb at openjdk.org  Wed Mar 26 09:03:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Mar 2025 09:03:10 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <QDhrzMsuqlzO1HoZgqyMYeBLsZQ27tn771t2pnHvKnI=.5bf0ee68-739f-4f8d-9658-ebd78e645e4b@github.com>

On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

Can you coordinate with Naoto on this? There is a CSR in progress to switch Console back to using the java.base implementation by default.

src/java.base/share/classes/module-info.java line 172:

> 170:         java.rmi,
> 171:         jdk.charsets,
> 172:         jdk.internal.le,

What code in JLine is using shared secrets? I wonder what we need to change to avoid this.

src/java.base/share/classes/module-info.java line 304:

> 302:     exports sun.nio.cs to
> 303:         jdk.charsets,
> 304:         jdk.internal.le;

Same thing here.

src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 51:

> 49:     }
> 50: 
> 51:     private static void doReadImpl(Reader reader, Writer out, boolean password, int firstLineOffset, IntSupplier terminalWidthSupplier, CleanableBuffer result) throws IOException {

These overly long lines make it really hard to see the changes going forward so I think trim back some of these to make it easy to look at diffs in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/24242#issuecomment-2753642709
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2013662676
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2013664086
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2013660028

From jlahoda at openjdk.org  Wed Mar 26 10:28:12 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Mar 2025 10:28:12 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <QDhrzMsuqlzO1HoZgqyMYeBLsZQ27tn771t2pnHvKnI=.5bf0ee68-739f-4f8d-9658-ebd78e645e4b@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <QDhrzMsuqlzO1HoZgqyMYeBLsZQ27tn771t2pnHvKnI=.5bf0ee68-739f-4f8d-9658-ebd78e645e4b@github.com>
Message-ID: <XYGfrhpy_NdwaeqmFcSu4mMCEbHlxzUszYVnqrkdSbs=.7d218aaf-e11c-47ec-a969-b5fef4551d89@github.com>

On Wed, 26 Mar 2025 08:55:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you coordinate with Naoto on this? There is a CSR in progress to switch Console back to using the java.base implementation by default.

Right - but that still keeps the existing JLine-based provider, and so the problems it has still exist (albeit with a lower severity). This proposal is not the only sole possibility, of course. Other possibilities include removing the JLine-based provider, or fixing the problems in the JLine provider one-by-one. I don't object to any of these possibilities, although I didn't want to offer them in the first step.

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

PR Comment: https://git.openjdk.org/jdk/pull/24242#issuecomment-2753912618

From jlahoda at openjdk.org  Wed Mar 26 10:32:13 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Mar 2025 10:32:13 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <QDhrzMsuqlzO1HoZgqyMYeBLsZQ27tn771t2pnHvKnI=.5bf0ee68-739f-4f8d-9658-ebd78e645e4b@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <QDhrzMsuqlzO1HoZgqyMYeBLsZQ27tn771t2pnHvKnI=.5bf0ee68-739f-4f8d-9658-ebd78e645e4b@github.com>
Message-ID: <-0ekDcnXdmkipjv7K2IvGae-vH4_IgjzlIqdt_qGf8g=.b7f70888-a9e1-45f8-a5f8-6b8bb1bfa124@github.com>

On Wed, 26 Mar 2025 08:59:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> src/java.base/share/classes/module-info.java line 172:
> 
>> 170:         java.rmi,
>> 171:         jdk.charsets,
>> 172:         jdk.internal.le,
> 
> What code in JLine is using shared secrets? I wonder what we need to change to avoid this.

Oops, sorry. I forgot to remove these (qualified export of `jdk.internal.access` and `sun.nio.cs`) after a refactoring. Will remove them in a next update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2013832440

From naoto at openjdk.org  Thu Mar 27 19:41:19 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Mar 2025 19:41:19 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com>

On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

I am not very familiar with those escape sequences/modes in the native console, but looks good to me. Sharing the common part as the base looks reasonable.

src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 69:

> 67:                 case 4: break READ; //EOF/Ctrl-D
> 68:                 case 127:
> 69:                     //backspace:

Is it `delete`?

src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 198:

> 196: 
> 197:             if (it.hasNext()) {
> 198:                 out.append("\n\r");

I understand this is a simple console, but do we want to CR/LF/CRLF based on the platform?

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

PR Review: https://git.openjdk.org/jdk/pull/24242#pullrequestreview-2723057740
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2017409982
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2017488129

From naoto at openjdk.org  Thu Mar 27 20:51:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Mar 2025 20:51:31 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com>
Message-ID: <cvy-G4Mx57Bvi-w25R-YwWXPjc-TW9d3PM4IY6E1w6Y=.1f226b7f-a341-42cc-b7e9-153eeef634d3@github.com>

On Thu, 27 Mar 2025 19:29:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 198:
> 
>> 196: 
>> 197:             if (it.hasNext()) {
>> 198:                 out.append("\n\r");
> 
> I understand this is a simple console, but do we want to CR/LF/CRLF based on the platform?

`line.seprator` system property can be used here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2017581921

From ihse at openjdk.org  Mon Mar 31 12:40:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 31 Mar 2025 12:40:19 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <Go0jnBdFBgBcsb86XzAJcZuknRrplmnbiccL9fmLcLM=.56881e8b-3f26-44d2-8cfe-2bc43707a8cc@github.com>

On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

src/jdk.internal.le/windows/native/lible/WindowsTerminal.cpp line 32:

> 30: #include <stdlib.h>
> 31: #include <Windows.h>
> 32: //#include <wincon.h>

Should you really check in new files with commented-out code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020962013

From ihse at openjdk.org  Mon Mar 31 12:51:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 31 Mar 2025 12:51:37 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <xexGQMhmfpq6s_jSJ4wiNwpQxsbjd4Tjdci5Bn_76KI=.a3d057ea-aa0d-4760-a1fe-b47fd8c89abf@github.com>

On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

make/modules/jdk.internal.le/Lib.gmk line 30:

> 28: ################################################################################
> 29: 
> 30: ifeq ($(call isTargetOs, linux macosx windows), true)

You might want to sync with the AIX guys to see if this should be enabled there as well. The unix version seems quite portable, so I assume it will work with very few adjustments, if any. @MBaesken 

Otherwise, what will happen if you try to run this on a platform without the corresponding native library?

make/modules/jdk.internal.le/Lib.gmk line 35:

> 33:       NAME := le, \
> 34:       TOOLCHAIN := TOOLCHAIN_LINK_CXX, \
> 35:       OPTIMIZATION := LOW, \

We are trying to move away from using `LOW` as a default optimization level. If you believe this library is not performance critical, please use `SIZE` as the new default. Or, use `HIGHEST` if that gives performance benefits with no significant impact on library size.

make/modules/jdk.internal.le/Lib.gmk line 36:

> 34:       TOOLCHAIN := TOOLCHAIN_LINK_CXX, \
> 35:       OPTIMIZATION := LOW, \
> 36:       JDK_LIBS := java.base:libjava, \

A quick glance through the native code revealed no obvious calls to libjava functions. Are you sure this dependency is needed?

make/modules/jdk.internal.le/Lib.gmk line 37:

> 35:       OPTIMIZATION := LOW, \
> 36:       JDK_LIBS := java.base:libjava, \
> 37:       LIBS_unix := $(JDKLIB_LIBS) $(LIBCXX), \

LIBCXX is added automatically nowadays, so you can remove this entire line.

make/modules/jdk.internal.le/Lib.gmk line 38:

> 36:       JDK_LIBS := java.base:libjava, \
> 37:       LIBS_unix := $(JDKLIB_LIBS) $(LIBCXX), \
> 38:       LIBS_windows := $(JDKLIB_LIBS) user32.lib, \

JDKLIB_LIBS is not used anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020982841
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020979597
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020976254
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020977176
PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2020976750

From jlahoda at openjdk.org  Mon Mar 31 14:36:16 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Mar 2025 14:36:16 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <xexGQMhmfpq6s_jSJ4wiNwpQxsbjd4Tjdci5Bn_76KI=.a3d057ea-aa0d-4760-a1fe-b47fd8c89abf@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <xexGQMhmfpq6s_jSJ4wiNwpQxsbjd4Tjdci5Bn_76KI=.a3d057ea-aa0d-4760-a1fe-b47fd8c89abf@github.com>
Message-ID: <TfaENvG_IwNSEQR0WapDTTxshmyWq09M7cKu-qJpCRg=.79311dae-6aaf-4ea0-b62e-7bdafe9d24e9@github.com>

On Mon, 31 Mar 2025 12:43:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> make/modules/jdk.internal.le/Lib.gmk line 36:
> 
>> 34:       TOOLCHAIN := TOOLCHAIN_LINK_CXX, \
>> 35:       OPTIMIZATION := LOW, \
>> 36:       JDK_LIBS := java.base:libjava, \
> 
> A quick glance through the native code revealed no obvious calls to libjava functions. Are you sure this dependency is needed?

`CHECK_NULL` is used by the native code, originating in `jni_util.h`. But, looking at other libraries, seems that 

EXTRA_HEADER_DIRS := java.base:libjava,


should be enough (i.e. replacing `JDK_LIBS` with `EXTRA_HEADER_DIRS`). Is there some even better way?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021174881

From jlahoda at openjdk.org  Mon Mar 31 15:06:56 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Mar 2025 15:06:56 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v2]
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <cxMa8BqER0u1zaLLq5GrONT306JD_srvn1f5DqYWFVc=.16c0a034-825d-4b14-b8e8-8212f11cc720@github.com>

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

Jan Lahoda has updated the pull request incrementally with four additional commits since the last revision:

 - Cleanup, fixing tests.
 - Adjusting JShell defaults.
 - Fixing tests.
 - Cleanup - updated specification will permit requires transitive java.base; for all classfile versions; java.se no longer participates in preview.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/46c8454a..cffcf851

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

  Stats: 306 lines in 18 files changed: 219 ins; 50 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/23801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23801/head:pull/23801

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

From jlahoda at openjdk.org  Mon Mar 31 17:08:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Mar 2025 17:08:09 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com>
Message-ID: <ZVVKSmaSBdy0CatH5rvVES-3D-P7kRkUhjH-u3RfI5M=.98654194-bd78-4401-a6c3-600b566e3b49@github.com>

On Thu, 27 Mar 2025 18:28:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
>> 
>> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
>> 
>> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.
>
> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 69:
> 
>> 67:                 case 4: break READ; //EOF/Ctrl-D
>> 68:                 case 127:
>> 69:                     //backspace:
> 
> Is it `delete`?

I don't think so. Delete is an escape sequence (`\033[3~`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021413402

From jlahoda at openjdk.org  Mon Mar 31 17:08:10 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Mar 2025 17:08:10 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <cvy-G4Mx57Bvi-w25R-YwWXPjc-TW9d3PM4IY6E1w6Y=.1f226b7f-a341-42cc-b7e9-153eeef634d3@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com>
 <cvy-G4Mx57Bvi-w25R-YwWXPjc-TW9d3PM4IY6E1w6Y=.1f226b7f-a341-42cc-b7e9-153eeef634d3@github.com>
Message-ID: <rmsA0xBjCBGXoI4he5dKtOKkG-YQQ_SgwM7GjHECZjk=.1f9bc540-8ee1-4a09-94d7-df4608e88f17@github.com>

On Thu, 27 Mar 2025 20:48:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 198:
>> 
>>> 196: 
>>> 197:             if (it.hasNext()) {
>>> 198:                 out.append("\n\r");
>> 
>> I understand this is a simple console, but do we want to CR/LF/CRLF based on the platform?
>
> `line.seprator` system property can be used here

When the terminal is in the raw/unprocessed mode, I believe `\n` is only moving the cursor to the next line (without changing the column), and `\r` is doing carriage return. So, to move the cursor to the first character of the next line, both are needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021410890

From naoto at openjdk.org  Mon Mar 31 17:20:18 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 31 Mar 2025 17:20:18 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <ZVVKSmaSBdy0CatH5rvVES-3D-P7kRkUhjH-u3RfI5M=.98654194-bd78-4401-a6c3-600b566e3b49@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <7AW84O5cby34ZbxiYS3yErSCcJUkWo0V3SzAplMGI9Q=.8b902714-e8fe-41c8-89ea-f40a4d8c3d23@github.com>
 <ZVVKSmaSBdy0CatH5rvVES-3D-P7kRkUhjH-u3RfI5M=.98654194-bd78-4401-a6c3-600b566e3b49@github.com>
Message-ID: <MkoUjrwK63V0ySf99b_Wd5hTcH26PB27VrcD1pu7cEA=.a6bde8bb-6305-4260-ab80-9800a0a0b942@github.com>

On Mon, 31 Mar 2025 17:04:55 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 69:
>> 
>>> 67:                 case 4: break READ; //EOF/Ctrl-D
>>> 68:                 case 127:
>>> 69:                     //backspace:
>> 
>> Is it `delete`?
>
> I don't think so. Delete is an escape sequence (`\033[3~`).

Hmm, that's interesting. In ASCII control codes, 127 is defined as `Delete` and 08 is defined as `Backspace`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021427938

From duke at openjdk.org  Mon Mar 31 17:25:17 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 31 Mar 2025 17:25:17 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <JErS11pMX4tnsU9d2zKYurOt4KVlEK7ETUkOFP3zb_U=.80721911-7aef-4d04-9f84-994f214f1fee@github.com>

On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `java.io.Console` has several backends: a simple on in `java.base`, a more convenient one in `jdk.internal.le` (with line-reading based on JLine) and one for JShell.
> 
> The backend based on JLine is proving to be a somewhat problematic - JLine is very powerful, possibly too powerful and complex for the simple task of editing a line with no completion, no history, no variables, no commands, etc. As a consequence, there are inevitable sharp edges in this backend.
> 
> The idea in this PR is to replace the use of JLine in the `jdk.internal.le` backend with a simple escape code interpreter, that only handles a handful of keys/codes (left/right arrow, home, end, delete, backspace, enter), and ignores the rest. The goal is to have something simple with less surprising behavior.

src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java line 75:

> 73:                     }
> 74:                     continue READ;
> 75:                 case '\033':

If this is meant to be platform-agnostic, is it really safe to make these assumptions about the ability to produce or interpret escape codes and to make assumptions about their behavior on the user's terminal? I don't think it would even be safe to assume a single terminal type or interpretation on POSIX-type OSes; that's what things like `terminfo`/`termcap` are supposed to be for, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24242#discussion_r2021436018

From jlahoda at openjdk.org  Mon Mar 31 17:40:25 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 31 Mar 2025 17:40:25 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v3]
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <uQdqdh861qc_8dlxW7tPGmhwY1NZ43LQ8vrtI8NIAB8=.93fdceb0-8def-4b2f-8e5d-badd994b7040@github.com>

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

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

  Fixing test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/cffcf851..067a0444

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

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

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