From liach at openjdk.org  Tue Apr  1 00:26:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Apr 2025 00:26:11 GMT
Subject: RFR: 8350983: JShell LocalExecutionControl only needs stopCheck()
 on backward branches [v2]
In-Reply-To: <lu40ZUdMUm8ZzR0e5HbcKL78mqbFpHJeTM2fyThQkCY=.f62146b9-d01a-48ed-ba95-763bd42cf31e@github.com>
References: <tA7keLk1KvwpYTzVqbn60HNzHNzEFs8Pi93vf7mW5h0=.905627b5-283c-47f6-a979-03208b70ef47@github.com>
 <lu40ZUdMUm8ZzR0e5HbcKL78mqbFpHJeTM2fyThQkCY=.f62146b9-d01a-48ed-ba95-763bd42cf31e@github.com>
Message-ID: <_ysL6C38TeE5R6nu-d_CA9kxe_DclljMtDsk962Rl2c=.66d51bd3-ab38-4f14-9097-c5087f0e819a@github.com>

On Mon, 3 Mar 2025 15:19:22 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 ?
>
> 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.

@lahodaj Can you take a look at this?

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

PR Comment: https://git.openjdk.org/jdk/pull/23850#issuecomment-2767706000

From jlahoda at openjdk.org  Tue Apr  1 11:22:22 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 1 Apr 2025 11:22:22 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <JErS11pMX4tnsU9d2zKYurOt4KVlEK7ETUkOFP3zb_U=.80721911-7aef-4d04-9f84-994f214f1fee@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <JErS11pMX4tnsU9d2zKYurOt4KVlEK7ETUkOFP3zb_U=.80721911-7aef-4d04-9f84-994f214f1fee@github.com>
Message-ID: <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com>

On Mon, 31 Mar 2025 17:22:45 GMT, David M. Lloyd <duke 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?

In theory, yes, that's what `terminfo` is supposed to do. But `terminfo` has its own set of problems, and what we get from a terminal and what we send to the terminal is so simple and generally supported, that it should be possible to make it work on all realistic terminals(*). Or is there a particular terminal you have in mind?

(*) I admit I've forgot that `\E[7~`/`\E[8~` is Home/End as well. I'll fix that.

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

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

From duke at openjdk.org  Tue Apr  1 14:26:48 2025
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 1 Apr 2025 14:26:48 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <JErS11pMX4tnsU9d2zKYurOt4KVlEK7ETUkOFP3zb_U=.80721911-7aef-4d04-9f84-994f214f1fee@github.com>
 <--xCs-W_bE8JdYjHC9nAU1gfTX_JGB98nzi-_VAaE6s=.5ea1f212-ab4c-4b30-80af-08061e7ebdb0@github.com>
Message-ID: <HSMApPaJ2LeG91zr6lt3AV9760v3lMLEgonwtEp_Mjg=.87e1e4b4-4070-4b93-93d8-0abf36cf82cd@github.com>

On Tue, 1 Apr 2025 11:18:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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?
>
> In theory, yes, that's what `terminfo` is supposed to do. But `terminfo` has its own set of problems, and what we get from a terminal and what we send to the terminal is so simple and generally supported, that it should be possible to make it work on all realistic terminals(*). Or is there a particular terminal you have in mind?
> 
> (*) I admit I've forgot that `\E[7~`/`\E[8~` is Home/End as well. I'll fix that.

I suppose I don't have a particular terminal in mind. But at the very least, maybe some documentation somewhere should reference e.g. [ECMA-48](https://ecma-international.org/publications-and-standards/standards/ecma-48/) as the basis for the behaviors of the console?

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

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

From jlahoda at openjdk.org  Wed Apr  2 11:12:55 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 2 Apr 2025 11:12:55 GMT
Subject: RFR: 8353545: Improve debug info for StartOptionTest
Message-ID: <8r7G3Q8NIFqXRFB8wwKQ7Yj5UclhrhPN354fak_TaFs=.9a96c2a8-b7aa-4c5c-95de-6ec17a473220@github.com>

The `jdk/jshell/ToolProviderTest.java` is intermittently failing. It is not clear why, so this PR attempts to add some more debug info (printing all the remaining output when the output check fails), which hopefully will help to determine the cause of the failures.

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

Commit messages:
 - 8353545: Improve debug info for StartOptionTest

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

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

From asotona at openjdk.org  Wed Apr  2 13:17:53 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 2 Apr 2025 13:17:53 GMT
Subject: RFR: 8353545: Improve debug info for StartOptionTest
In-Reply-To: <8r7G3Q8NIFqXRFB8wwKQ7Yj5UclhrhPN354fak_TaFs=.9a96c2a8-b7aa-4c5c-95de-6ec17a473220@github.com>
References: <8r7G3Q8NIFqXRFB8wwKQ7Yj5UclhrhPN354fak_TaFs=.9a96c2a8-b7aa-4c5c-95de-6ec17a473220@github.com>
Message-ID: <-pyjxWovkqwTvBp4GkN50Y9-8Y-sJjyk-51ryCZF9a4=.c69acaf1-7297-46b6-80cf-72f157c77c77@github.com>

On Wed, 2 Apr 2025 11:06:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `jdk/jshell/ToolProviderTest.java` is intermittently failing. It is not clear why, so this PR attempts to add some more debug info (printing all the remaining output when the output check fails), which hopefully will help to determine the cause of the failures.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24376#pullrequestreview-2736242394

From jlahoda at openjdk.org  Wed Apr  2 13:22:14 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 2 Apr 2025 13:22:14 GMT
Subject: Integrated: 8353545: Improve debug info for StartOptionTest
In-Reply-To: <8r7G3Q8NIFqXRFB8wwKQ7Yj5UclhrhPN354fak_TaFs=.9a96c2a8-b7aa-4c5c-95de-6ec17a473220@github.com>
References: <8r7G3Q8NIFqXRFB8wwKQ7Yj5UclhrhPN354fak_TaFs=.9a96c2a8-b7aa-4c5c-95de-6ec17a473220@github.com>
Message-ID: <53j4hWpgqQx-Ekju1VcCor3HaNZW3LrmnV4CGPQPVsk=.796d8829-dd98-468f-80b0-6b2e016ebd45@github.com>

On Wed, 2 Apr 2025 11:06:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The `jdk/jshell/ToolProviderTest.java` is intermittently failing. It is not clear why, so this PR attempts to add some more debug info (printing all the remaining output when the output check fails), which hopefully will help to determine the cause of the failures.

This pull request has now been integrated.

Changeset: 23eb648c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23eb648cae1ccadbca0fd654d4fbc28a1b8375e2
Stats:     26 lines in 1 file changed: 16 ins; 0 del; 10 mod

8353545: Improve debug info for StartOptionTest

Reviewed-by: asotona

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

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

From vromero at openjdk.org  Wed Apr  2 15:31:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Apr 2025 15:31:50 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v3]
In-Reply-To: <uQdqdh861qc_8dlxW7tPGmhwY1NZ43LQ8vrtI8NIAB8=.93fdceb0-8def-4b2f-8e5d-badd994b7040@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
 <uQdqdh861qc_8dlxW7tPGmhwY1NZ43LQ8vrtI8NIAB8=.93fdceb0-8def-4b2f-8e5d-badd994b7040@github.com>
Message-ID: <KW1sr7U1lvmdaLFBYNLPsaJmhYg0Qzrdp6q2AlZguio=.bf568d2f-0f2e-4354-8d72-ada395190308@github.com>

On Mon, 31 Mar 2025 17:40:25 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
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 340:

> 338:      */
> 339:     static Startup defaultStartup(int sourceLevel, boolean preview, MessageHandler mh) {
> 340:         boolean startup24 = sourceLevel < 25;

should we use a constant here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2025076240

From jlahoda at openjdk.org  Wed Apr  2 16:59:16 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 2 Apr 2025 16:59:16 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v4]
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <BZ0t27h2QH3LJtwIz8A4iY2A4BAM9vNxqZobc188_Jo=.a9493884-df0e-4fe3-8319-3d7db6b5d619@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:

  Reflecting review feedback - avoiding hardcoded constants.

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

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

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

  Stats: 19 lines in 3 files changed: 4 ins; 0 del; 15 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  Wed Apr  2 16:59:17 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 2 Apr 2025 16:59:17 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v3]
In-Reply-To: <KW1sr7U1lvmdaLFBYNLPsaJmhYg0Qzrdp6q2AlZguio=.bf568d2f-0f2e-4354-8d72-ada395190308@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
 <uQdqdh861qc_8dlxW7tPGmhwY1NZ43LQ8vrtI8NIAB8=.93fdceb0-8def-4b2f-8e5d-badd994b7040@github.com>
 <KW1sr7U1lvmdaLFBYNLPsaJmhYg0Qzrdp6q2AlZguio=.bf568d2f-0f2e-4354-8d72-ada395190308@github.com>
Message-ID: <gI_maoKoTTCF6UhWorg8123NwVnIR2xnKRj6-ZrPhDI=.b0c60041-3cb2-41ff-be0f-d6f6f7ada547@github.com>

On Wed, 2 Apr 2025 15:23:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing test.
>
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java line 340:
> 
>> 338:      */
>> 339:     static Startup defaultStartup(int sourceLevel, boolean preview, MessageHandler mh) {
>> 340:         boolean startup24 = sourceLevel < 25;
> 
> should we use a constant here?

Yes, there should be a constant. Done here:
https://github.com/openjdk/jdk/pull/23801/commits/d66703c1cb4f9f532f9a98181b598fa45e55ef73
Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2025240134

From vromero at openjdk.org  Wed Apr  2 17:43:51 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Apr 2025 17:43:51 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v4]
In-Reply-To: <BZ0t27h2QH3LJtwIz8A4iY2A4BAM9vNxqZobc188_Jo=.a9493884-df0e-4fe3-8319-3d7db6b5d619@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
 <BZ0t27h2QH3LJtwIz8A4iY2A4BAM9vNxqZobc188_Jo=.a9493884-df0e-4fe3-8319-3d7db6b5d619@github.com>
Message-ID: <W0lNT-yj7J2JsxeQUhEXolh6hbYvj5YjlBHEjqDDVSg=.700aa568-3575-47a5-a421-49705e3ddee0@github.com>

On Wed, 2 Apr 2025 16:59:16 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
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - avoiding hardcoded constants.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2737083010

From acobbs at openjdk.org  Wed Apr  2 23:32:22 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 2 Apr 2025 23:32:22 GMT
Subject: RFR: 8353487: JShell LocalExecutionControl should allow decorating the
 execution task
Message-ID: <pHDQYr9-TPcRILXosAhrbBycdyeAQlVmNrYmC4X66c4=.6469dfad-15be-49d7-a3be-66a8ac3aecc5@github.com>

This PR adds the ability for subclasses of JShell's `LocalExecutionControl` to configure thread-local context in the execution thread that snippets execute in. Please see [JDK-8353487](https://bugs.openjdk.org/browse/JDK-8353487) for more details & rationale.

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

Commit messages:
 - Add method LocalExecutionControl.decorateExecution().

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

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

From jlahoda at openjdk.org  Thu Apr  3 17:59:52 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Apr 2025 17:59:52 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v2]
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <FDzyvEx1pI_W1dYDZeQZWpnjRgsQNpzJse-bULBTDeE=.28698822-58a8-48e1-a587-22c76c87e5b8@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.

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

 - Using control characters to get backspace control character.
 - If there's no native library available, fall back to the standard provider.
 - Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24242/files
  - new: https://git.openjdk.org/jdk/pull/24242/files/77c41e46..d5176d68

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

  Stats: 152 lines in 11 files changed: 114 ins; 13 del; 25 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 jlahoda at openjdk.org  Thu Apr  3 18:12:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Apr 2025 18:12:54 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v2]
In-Reply-To: <FDzyvEx1pI_W1dYDZeQZWpnjRgsQNpzJse-bULBTDeE=.28698822-58a8-48e1-a587-22c76c87e5b8@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <FDzyvEx1pI_W1dYDZeQZWpnjRgsQNpzJse-bULBTDeE=.28698822-58a8-48e1-a587-22c76c87e5b8@github.com>
Message-ID: <blxPSfLmCXSPu0MeLGdz0-VjsQ_ZMkB6CHKv_3WoM14=.eb5062bd-0a60-405b-abf4-8b261adb39e1@github.com>

On Thu, 3 Apr 2025 17:59:52 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.
>
> Jan Lahoda has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Using control characters to get backspace control character.
>  - If there's no native library available, fall back to the standard provider.
>  - Reflecting review feedback.

I have updated the PR based on most of the review comments so far:
- removed the unnecessary qualified exports (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a)
- reduced line lengths (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a)
- cleaned comments in the C code (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a)
- cleaned up the makefiles (https://github.com/openjdk/jdk/pull/24242/commits/91fa1b28e0436e55eed9cdee07e0e28c25bf666a)
- if the native library (for UNIX) is not available, fall back to the simple/default provider (although support for AIX would be great, of course) (https://github.com/openjdk/jdk/pull/24242/commits/c6256eeeabfd73e7e67bf7f8c18c337e6bb92534)
- I realized the backspace value can (and should) be read from the terminal as a control character, so I did that (https://github.com/openjdk/jdk/pull/24242/commits/d5176d68e8cc73914a0efef45a60f0ff03885bcc)

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

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

From jlahoda at openjdk.org  Thu Apr  3 18:12:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 3 Apr 2025 18:12:54 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v3]
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <NJGBm2tD0GJv3rqqrXY5ti39xWXKohfu0LHeaffIFNs=.2193358d-6924-4cd4-96f8-41182def4f94@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.

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

 - Merge branch 'master' into JDK-8352693
 - Using control characters to get backspace control character.
 - If there's no native library available, fall back to the standard provider.
 - Reflecting review feedback.
 - 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=02
  Stats: 2519 lines in 19 files changed: 1920 ins; 592 del; 7 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 jlahoda at openjdk.org  Fri Apr  4 09:13:35 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Apr 2025 09:13:35 GMT
Subject: RFR: 8353581: Support for `import module` in JShell's code completion
Message-ID: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>

Adding support for `import module ` to JShell's code completion.

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

Commit messages:
 - Fixing typo in test.
 - 8353581: Support for `import module` in JShell's code completion

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

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

From ihse at openjdk.org  Fri Apr  4 14:27:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Apr 2025 14:27:53 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v3]
In-Reply-To: <NJGBm2tD0GJv3rqqrXY5ti39xWXKohfu0LHeaffIFNs=.2193358d-6924-4cd4-96f8-41182def4f94@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
 <NJGBm2tD0GJv3rqqrXY5ti39xWXKohfu0LHeaffIFNs=.2193358d-6924-4cd4-96f8-41182def4f94@github.com>
Message-ID: <dhZl33lSZkIzVyFtczo2qy4s4Ti_uVAsJfBL_NDFw3U=.502a77fd-797c-42de-b549-3a8b9592ed14@github.com>

On Thu, 3 Apr 2025 18:12:54 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.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8352693
>  - Using control characters to get backspace control character.
>  - If there's no native library available, fall back to the standard provider.
>  - Reflecting review feedback.
>  - Removing trailing whitespace
>  - 8352693: Use a simpler console reader instead of JLine for System.console()

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

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

Can you please insert the standardized header we use for native libraries? (These are extremely helpful to find/locate where certain libraries are built, since there is no existing proper IDE support for makefiles.)

Suggestion:

  ##############################################################################
  ## Build lible
  ##############################################################################

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

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

From jlahoda at openjdk.org  Fri Apr  4 15:56:51 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 4 Apr 2025 15:56:51 GMT
Subject: RFR: 8353487: JShell LocalExecutionControl should allow decorating
 the execution task
In-Reply-To: <pHDQYr9-TPcRILXosAhrbBycdyeAQlVmNrYmC4X66c4=.6469dfad-15be-49d7-a3be-66a8ac3aecc5@github.com>
References: <pHDQYr9-TPcRILXosAhrbBycdyeAQlVmNrYmC4X66c4=.6469dfad-15be-49d7-a3be-66a8ac3aecc5@github.com>
Message-ID: <OEu7gwkddnF0oiJkIsxfgyBwOy0ad6e8KpdaH38dZ-I=.cd9aae1c-46bd-4ebb-8667-ed7951b804aa@github.com>

On Wed, 2 Apr 2025 23:26:05 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR adds the ability for subclasses of JShell's `LocalExecutionControl` to configure thread-local context in the execution thread that snippets execute in. Please see [JDK-8353487](https://bugs.openjdk.org/browse/JDK-8353487) for more details & rationale.

I wonder how generic are the snippets used - for some types of snippets, it might be possible to put some code around the original snippet directly in the snippet. That would alleviate the need to add a new API. But presumably it would only work for some types of snippets.

For the API itself - just an idea, would having a method `doInvoke` along these lines work:

public Object doInvoke(Method m) throws Exception {
    return doitMethod.invoke(null, new Object[0]);
}

?

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

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

From acobbs at openjdk.org  Fri Apr  4 16:55:11 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 4 Apr 2025 16:55:11 GMT
Subject: RFR: 8353487: JShell LocalExecutionControl should allow decorating
 the execution task [v2]
In-Reply-To: <pHDQYr9-TPcRILXosAhrbBycdyeAQlVmNrYmC4X66c4=.6469dfad-15be-49d7-a3be-66a8ac3aecc5@github.com>
References: <pHDQYr9-TPcRILXosAhrbBycdyeAQlVmNrYmC4X66c4=.6469dfad-15be-49d7-a3be-66a8ac3aecc5@github.com>
Message-ID: <Rq2viLuxGoKgwIChgpF1kA6Yn6BvJ9PojcFdVYc_Clo=.bda99a31-337c-476a-a6a6-11090fb94805@github.com>

> This PR adds the ability for subclasses of JShell's `LocalExecutionControl` to configure thread-local context in the execution thread that snippets execute in. Please see [JDK-8353487](https://bugs.openjdk.org/browse/JDK-8353487) for more details & rationale.

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

  Replace decorateExecution() with doInvoke() per review suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24398/files
  - new: https://git.openjdk.org/jdk/pull/24398/files/68cccbf1..8c472446

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

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

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

From acobbs at openjdk.org  Fri Apr  4 16:55:11 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 4 Apr 2025 16:55:11 GMT
Subject: RFR: 8353487: JShell LocalExecutionControl should allow decorating
 the execution task
In-Reply-To: <OEu7gwkddnF0oiJkIsxfgyBwOy0ad6e8KpdaH38dZ-I=.cd9aae1c-46bd-4ebb-8667-ed7951b804aa@github.com>
References: <pHDQYr9-TPcRILXosAhrbBycdyeAQlVmNrYmC4X66c4=.6469dfad-15be-49d7-a3be-66a8ac3aecc5@github.com>
 <OEu7gwkddnF0oiJkIsxfgyBwOy0ad6e8KpdaH38dZ-I=.cd9aae1c-46bd-4ebb-8667-ed7951b804aa@github.com>
Message-ID: <w9T5FFPVqfmIxkKJtQfpf1e-WxWGhnad-_BvC2NaRb0=.7cd87157-3bf3-4654-9edf-82791886536a@github.com>

On Fri, 4 Apr 2025 15:53:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I wonder how generic are the snippets used - for some types of snippets, it might be possible to put some code around the original snippet directly in the snippet. That would alleviate the need to add a new API. But presumably it would only work for some types of snippets.

Yes, sort of - it's already possible to modify the snippet bytecode itself of course because the `ExecutionProvider` is who loads it. That works for things like imposing time limits, etc., but it doesn't work so well for "wrapping" the execution because (a) you have to know what the secret method is that is going to be invoked (not hard - it's called `do_it()`, but kludgey), and (b) you would have to insert an INVOKESTATIC that calls into your `ExecutionProvider`, which means your `ExecutionProvider` must be available via the class loader that the snippet uses, and this is not guaranteed.

> For the API itself - just an idea, would having a method `doInvoke` along these lines work:
> 
> ```
> public Object doInvoke(Method m) throws Exception {
>     return doitMethod.invoke(null, new Object[0]);
> }
> ```

Yes that would work just as well. A third option would be to define a pair like `executionStart()` and `executionFinish()`.

I think your idea of a `doInvoke()` is actually a bit simpler/better, so I've updated that in 8c472446e66 and also updated the CSR.

Thanks for taking a look.

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

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

From duke at openjdk.org  Sun Apr  6 10:54:07 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Sun, 6 Apr 2025 10:54:07 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v57]
In-Reply-To: <M06P1ym-MnvjB2Z-v9hfGFjXV2RbBeIqg0EMzWr9LNU=.b363d892-f5da-42dc-b53d-7a9a0ed1689e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <M06P1ym-MnvjB2Z-v9hfGFjXV2RbBeIqg0EMzWr9LNU=.b363d892-f5da-42dc-b53d-7a9a0ed1689e@github.com>
Message-ID: <uQ8FmRZ1dc9iWSbVqOOigL7x4AQbgUcwzpGFfR2jfg4=.1ede3b61-86e9-434c-b84c-8e87dfe6378e@github.com>

On Wed, 31 Jan 2024 10:03:23 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Update summary in ExactnessConversionsSupportTest
>  - Address review by Jan
>  - Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
>  - Small fix in Javadoc
>  - Tidy up Javadoc of Lower.visitTypeTest
>  - Tidy up Javadoc of IllegalArgumentException in typeSwitch
>  - Improve readability in SwitchBootstraps
>  - Update year
>  - Cleanup redundant clone
>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 676:

> 674:         }
> 675:         else if (selectorType.equals(targetType) ||
> 676:                 ((selectorType.equals(byte.class) && !targetType.equals(char.class)) ||

Suggestion:

                ((selectorType.equals(byte.class) && targetType.isPrimitve() && !targetType.equals(boolean.class) && !targetType.equals(char.class)) ||

Otherwise, `SwitchBootstraps.typeSwitch` produces wrong results for `byte`:

var l = MethodHandles.lookup();
var shortType = MethodType.methodType(int.class, short.class, int.class);
var byteType = MethodType.methodType(int.class, byte.class, int.class);

CallSite shortSwitch = SwitchBootstraps.typeSwitch(l, "", shortType, String.class);
CallSite byteSwitch = SwitchBootstraps.typeSwitch(l, "", byteType, String.class);

int shortIndex = (int) shortSwitch.getTarget().invokeExact((short) 1, 0);
int byteIndex = (int) byteSwitch.getTarget().invokeExact((byte) 1, 0);

System.out.println(shortIndex == 1); // true
System.out.println(byteIndex == 1); // false
System.out.println(byteIndex); // 0

This would cause this code to misbehave (if it would compile, which it doesn't):

byte b = 1;
switch (b) {
    case String s -> System.out.println("How did we get here? byte is " + s.getClass());
}

So it isn't really a problem with `javac` but could cause problems for other users of `SwitchBootstraps`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r2030113548

From jlahoda at openjdk.org  Mon Apr  7 07:01:34 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 07:01:34 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
Message-ID: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@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`)

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

Commit messages:
 - Moving tests as suggested, removing unused import.
 - Fixing test.
 - Fixing test.
 - Fixing test.
 - Removing unnecessary enable preview from tests.
 - Merge branch 'master' into finalize-concise-source-files
 - Merge remote-tracking branch 'stuart-marks/JavaLangIO' into finalize-concise-source-files
 - Responses to Alan's comments: clean up readln() and align with class spec.
 - Clean up some charset stuff, use stdin.encoding property.
 - Merge branch 'master' into JavaLangIO
 - ... and 16 more: https://git.openjdk.org/jdk/compare/1c2a5533...a5d223e1

Changes: https://git.openjdk.org/jdk/pull/24438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344706
  Stats: 962 lines in 56 files changed: 294 ins; 585 del; 83 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 duke at openjdk.org  Mon Apr  7 07:01:34 2025
From: duke at openjdk.org (Luca Kellermann)
Date: Mon, 7 Apr 2025 07:01:34 GMT
Subject: RFR: 8344706: Compiler Implementation of 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: <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@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`)

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

> 120:     public static void print(Object obj) {
> 121:         System.out.print(obj);
> 122:         System.out.flush();

Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between?


var out = System.out;
out.print(obj);
out.flush();

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

> 145:         } catch (IOException ioe) {
> 146:             throw new IOError(ioe);
> 147:         }

Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors.

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

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

From liach at openjdk.org  Mon Apr  7 07:01:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 07:01:34 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
Message-ID: <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>

On Sat, 5 Apr 2025 00:55:55 GMT, Luca Kellermann <duke 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`)
>
> src/java.base/share/classes/java/lang/IO.java line 122:
> 
>> 120:     public static void print(Object obj) {
>> 121:         System.out.print(obj);
>> 122:         System.out.flush();
> 
> Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between?
> 
> 
> var out = System.out;
> out.print(obj);
> out.flush();

This code is not that perf sensitive, guess it is fine as-is

> src/java.base/share/classes/java/lang/IO.java line 147:
> 
>> 145:         } catch (IOException ioe) {
>> 146:             throw new IOError(ioe);
>> 147:         }
> 
> Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors.

This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup.

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

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

From liach at openjdk.org  Mon Apr  7 07:01:35 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 07:01:35 GMT
Subject: RFR: 8344706: Compiler Implementation of 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: <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@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`)

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

> 181:      * @return the internal BufferedReader instance
> 182:      */
> 183:     static synchronized BufferedReader reader() {

Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader?

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

> 1: /*

Shouldn't the package of this test be moved to java/lang?

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

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

From jlahoda at openjdk.org  Mon Apr  7 07:05:00 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 07:05:00 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com>
Message-ID: <MU6afsTvy6Jr1SA2par6YCTx_Jgu_JZQkBsT4rOasJM=.72a070b2-da8c-4ad2-8cc0-310518f5f5dc@github.com>

On Sat, 5 Apr 2025 00:20:29 GMT, Chen Liang <liach 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`)
>
> src/java.base/share/classes/java/lang/IO.java line 183:
> 
>> 181:      * @return the internal BufferedReader instance
>> 182:      */
>> 183:     static synchronized BufferedReader reader() {
> 
> Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader?

I believe there needs to be some barriers (at least `volatile`) even for getting the already initialized reader. And then, given the code here, it is probably fine and less error prone to simply use `synchronized` that something more complex.

But, given we'll hopefully have `@StableValue` soon, maybe we could use that? What do you think @stuart-marks?

Thanks!

> test/jdk/java/io/IO/IO.java line 1:
> 
>> 1: /*
> 
> Shouldn't the package of this test be moved to java/lang?

Done:
https://github.com/openjdk/jdk/pull/24438/commits/a5d223e14cadeb0e331d66d9030b780651f0cd64
Thanks!

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

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

From cstein at openjdk.org  Mon Apr  7 07:19:54 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 7 Apr 2025 07:19:54 GMT
Subject: RFR: 8344706: Compiler Implementation of 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: <a_FFMPCgrOOcjvOoAitZaR4nURb3F0pEQ6WuHISvMbc=.d27ae8ff-ea3b-4c3f-a425-cc407e7b71d5@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`)

Changes in source launcher related tests look good.

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

Marked as reviewed by cstein (Committer).

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

From alanb at openjdk.org  Mon Apr  7 09:14:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 09:14:52 GMT
Subject: RFR: 8344706: Compiler Implementation of 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: <ebNZEAX7tHbGLlV9SYXIZ4_fKy7qxjq9HuPLcUfomiw=.08521db0-0729-4cc1-8fac-73c531b980ce@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`)

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

> 43:  * UTF-8 is used instead. These internal objects are created upon the first call to
> 44:  * either of the {@code readln} methods and are stored for subsequent reuse by these
> 45:  * methods.

@stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"?

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

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

From alanb at openjdk.org  Mon Apr  7 09:20:59 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 7 Apr 2025 09:20:59 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
 <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>
Message-ID: <fQmsn6MTmrifwu3n8449mqqV9AxQz0iFojl0qtX8PM8=.a82b535f-cd9f-4fe2-83a5-ee48219c1ed7@github.com>

On Sat, 5 Apr 2025 02:30:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/IO.java line 147:
>> 
>>> 145:         } catch (IOException ioe) {
>>> 146:             throw new IOError(ioe);
>>> 147:         }
>> 
>> Was `UncheckedIOException` considered? It might be better for beginners to learn throwing exceptions instead of errors.
>
> This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup.

Someone is bound to ask why the readln method throw but the println methods don't.

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

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

From jlahoda at openjdk.org  Mon Apr  7 15:50:11 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 15:50:11 GMT
Subject: RFR: 8353332: Test jdk/jshell/ToolProviderTest.java failed in relation
 to enable-preview
Message-ID: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>

JShell keeps persisted preferences in `java.util.prefs.Preferences`. But, during tests, an empty persistence is typically used, to avoid values persisted on the test machine to affect the test.

But, in case of `jdk/jshell/ToolProviderTest.java`, this is not done, as JShell is started using the `Tool` interface.

This patch strives to fix that, by adding indirection in building JShell in `JShellToolProvider`, and using that in the test to inject empty persistence.

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

Commit messages:
 - 8353332: Test jdk/jshell/ToolProviderTest.java failed in relation to enable-preview

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

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

From jpai at openjdk.org  Mon Apr  7 16:23:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 7 Apr 2025 16:23:03 GMT
Subject: RFR: 8353332: Test jdk/jshell/ToolProviderTest.java failed in
 relation to enable-preview
In-Reply-To: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>
References: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>
Message-ID: <8fgizSe7tt89ig8SIQndRmkpJpPwAqSdk0wcIUSI6qI=.ca719252-bf55-4174-a406-98f889796906@github.com>

On Mon, 7 Apr 2025 15:44:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell keeps persisted preferences in `java.util.prefs.Preferences`. But, during tests, an empty persistence is typically used, to avoid values persisted on the test machine to affect the test.
> 
> But, in case of `jdk/jshell/ToolProviderTest.java`, this is not done, as JShell is started using the `Tool` interface.
> 
> This patch strives to fix that, by adding indirection in building JShell in `JShellToolProvider`, and using that in the test to inject empty persistence.
> 
> Thanks to @jaikiran for figuring out the probable cause.

I don't have knowledge of this area, but given what seems to be happening in this test and the code that I looked through briefly, this proposed change to provide a way for augmenting the building of the `JshellTool` seems reasonable to me.

I'll update the JBS issue once the CI runs that I've triggered (without this change) come back. That should tell us if local stored preferences is (the only thing) that's playing a role in these failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/24492#issuecomment-2783916202

From smarks at openjdk.org  Mon Apr  7 17:17:57 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 17:17:57 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
 <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>
Message-ID: <JtOekWN13HlD4unUmyly3tEY-wq81vfoqZijMJ403hM=.0a6451d9-29ee-4a81-8de2-bf80c851a971@github.com>

On Sat, 5 Apr 2025 02:31:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/IO.java line 122:
>> 
>>> 120:     public static void print(Object obj) {
>>> 121:         System.out.print(obj);
>>> 122:         System.out.flush();
>> 
>> Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between?
>> 
>> 
>> var out = System.out;
>> out.print(obj);
>> out.flush();
>
> This code is not that perf sensitive, guess it is fine as-is

I think there's a correctness angle. If you print something to a stream you want to flush the same stream. If System.out is changed in between (unlikely, but possible) then output destined for the old stream could be stranded in its buffer.

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

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

From smarks at openjdk.org  Mon Apr  7 17:28:52 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 17:28:52 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods
In-Reply-To: <MU6afsTvy6Jr1SA2par6YCTx_Jgu_JZQkBsT4rOasJM=.72a070b2-da8c-4ad2-8cc0-310518f5f5dc@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <49kjZQWwnSD9GEJTcXjwNSl6socEa0lOiQCr2M5Mmu8=.6a986db6-5a07-4811-bdc2-2e513c2e2f65@github.com>
 <MU6afsTvy6Jr1SA2par6YCTx_Jgu_JZQkBsT4rOasJM=.72a070b2-da8c-4ad2-8cc0-310518f5f5dc@github.com>
Message-ID: <L42YPWA8vfKYPfodFYiTwYh8ssUXoE7-PjexidUkG1o=.432c6d29-19e2-4431-a6b4-718aff121144@github.com>

On Mon, 7 Apr 2025 07:01:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/IO.java line 183:
>> 
>>> 181:      * @return the internal BufferedReader instance
>>> 182:      */
>>> 183:     static synchronized BufferedReader reader() {
>> 
>> Is the lock only inteneded for initialization, i.e. should it apply for simply getting the reader?
>
> I believe there needs to be some barriers (at least `volatile`) even for getting the already initialized reader. And then, given the code here, it is probably fine and less error prone to simply use `synchronized` that something more complex.
> 
> But, given we'll hopefully have `@StableValue` soon, maybe we could use that? What do you think @stuart-marks?
> 
> Thanks!

It's even more complex than `volatile`. If a thread comes along and reads a null here, it still needs to take a lock (or something) to prevent more than one thread from creating the BufferedReader and storing it back into the field. This leads down the path of double-checked locking, initialize-on-demand holder, etc.

It's not clear to me this is in such a critical path that it warrants adding any of this stuff. StableValue probably has the right semantics. However, it's not even in the JDK yet (though it is Targeted to 25 as of this moment). But I don't think we want to add a dependency on a Preview API.

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

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

From jlahoda at openjdk.org  Mon Apr  7 18:13:29 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 18:13:29 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <TfIZaTI8GZKhBnjmlV6Y09vyNFa2mg7PhtZiC9TfPOA=.7b327539-bb5c-4176-b106-995bf7ca19d1@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:

  Use local variable for System.out in print().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/a5d223e1..be8846e0

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

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 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 smarks at openjdk.org  Mon Apr  7 18:13:29 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 18:13:29 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <ebNZEAX7tHbGLlV9SYXIZ4_fKy7qxjq9HuPLcUfomiw=.08521db0-0729-4cc1-8fac-73c531b980ce@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <ebNZEAX7tHbGLlV9SYXIZ4_fKy7qxjq9HuPLcUfomiw=.08521db0-0729-4cc1-8fac-73c531b980ce@github.com>
Message-ID: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>

On Mon, 7 Apr 2025 09:12:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use local variable for System.out in print().
>
> src/java.base/share/classes/java/lang/IO.java line 45:
> 
>> 43:  * UTF-8 is used instead. These internal objects are created upon the first call to
>> 44:  * either of the {@code readln} methods and are stored for subsequent reuse by these
>> 45:  * methods.
> 
> @stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"? The class does speak of buffering and how it might impact code that mixes use of System.in and IO.readln so I agree with that part it's just the "internal objects" phrase that is confusing to read in this class.

I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder.

I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ?

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

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

From smarks at openjdk.org  Mon Apr  7 18:13:30 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 18:13:30 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
Message-ID: <TqjXi_0xULWpORApdiyPYtJWKlivtonqokzWl4q7HVc=.293e9323-42ff-4528-9cb9-0f639cf10ce8@github.com>

On Sat, 5 Apr 2025 00:55:55 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use local variable for System.out in print().
>
> src/java.base/share/classes/java/lang/IO.java line 122:
> 
>> 120:     public static void print(Object obj) {
>> 121:         System.out.print(obj);
>> 122:         System.out.flush();
> 
> Is it worth using a local variable to avoid calling `print` and `flush` on different streams in case `System.out` is reassigned in between?
> 
> 
> var out = System.out;
> out.print(obj);
> out.flush();

Updated as suggested; thanks @lukellmann .

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

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

From naoto at openjdk.org  Mon Apr  7 18:13:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 7 Apr 2025 18:13:30 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <TfIZaTI8GZKhBnjmlV6Y09vyNFa2mg7PhtZiC9TfPOA=.7b327539-bb5c-4176-b106-995bf7ca19d1@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <TfIZaTI8GZKhBnjmlV6Y09vyNFa2mg7PhtZiC9TfPOA=.7b327539-bb5c-4176-b106-995bf7ca19d1@github.com>
Message-ID: <LKg90m7sgoiieMmAZ_brMq4JUP9Y5E04d_RuX92-9hk=.721aefc8-da06-4eba-b787-674c09a15587@github.com>

On Mon, 7 Apr 2025 18:10:20 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:
> 
>   Use local variable for System.out in print().

test/jdk/java/lang/IO/IO/IO.java line 1:

> 1: /*

Is there reason to create a test subdirectory `IO` under `java.lang.IO` package?

test/jdk/java/lang/IO/IO/IO.java line 53:

> 51: /*
> 52:  * @test
> 53:  * @bug 8305457 8342936 8351435

Issue id needs to be added (and other test files too)

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

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

From smarks at openjdk.org  Mon Apr  7 18:38:22 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 18:38:22 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <fQmsn6MTmrifwu3n8449mqqV9AxQz0iFojl0qtX8PM8=.a82b535f-cd9f-4fe2-83a5-ee48219c1ed7@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
 <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>
 <fQmsn6MTmrifwu3n8449mqqV9AxQz0iFojl0qtX8PM8=.a82b535f-cd9f-4fe2-83a5-ee48219c1ed7@github.com>
Message-ID: <QJN2GI8wPOaiEsoVkXyOM7JeBKDQ42XpbkiTXJ_BhEQ=.d53f3352-7933-489e-8d76-44fb05e8754d@github.com>

On Mon, 7 Apr 2025 09:18:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This implementation is not to be emulated by beginners. If an Exception.is thrown here, a user might be tempted to add handlers in their code, while this is an issue with the setup.
>
> Someone is bound to ask why the readln method throw but the println methods don't.

The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason.

My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here.

UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard.

I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice.

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

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

From vromero at openjdk.org  Mon Apr  7 19:20:22 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Apr 2025 19:20:22 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <TfIZaTI8GZKhBnjmlV6Y09vyNFa2mg7PhtZiC9TfPOA=.7b327539-bb5c-4176-b106-995bf7ca19d1@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <TfIZaTI8GZKhBnjmlV6Y09vyNFa2mg7PhtZiC9TfPOA=.7b327539-bb5c-4176-b106-995bf7ca19d1@github.com>
Message-ID: <6w1YXrCnHGH5VifP_2jWinbKd0sGMlUeR1KOC8FJWXg=.af36af50-a7e7-4e76-9470-6a89bf58cf3e@github.com>

On Mon, 7 Apr 2025 18:13:29 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:
> 
>   Use local variable for System.out in print().

javac compiler related code and tests lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From liach at openjdk.org  Mon Apr  7 19:25:19 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 7 Apr 2025 19:25:19 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <ebNZEAX7tHbGLlV9SYXIZ4_fKy7qxjq9HuPLcUfomiw=.08521db0-0729-4cc1-8fac-73c531b980ce@github.com>
 <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>
Message-ID: <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com>

On Mon, 7 Apr 2025 18:08:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/IO.java line 45:
>> 
>>> 43:  * UTF-8 is used instead. These internal objects are created upon the first call to
>>> 44:  * either of the {@code readln} methods and are stored for subsequent reuse by these
>>> 45:  * methods.
>> 
>> @stuart-marks Can we rephrase this paragraph so that it doesn't use phrase "internal objects"? The class does speak of buffering and how it might impact code that mixes use of System.in and IO.readln so I agree with that part it's just the "internal objects" phrase that is confusing to read in this class.
>
> I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder.
> 
> I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ?

Can we rephrase the 1st sentence to read:
"The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters."

And remove the last "these internal objects" sentence.

And for the next paragraph, change the first line to:
"The `readln` methods may buffer additional bytes..."

So we remove references to "internal objects."

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

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

From smarks at openjdk.org  Mon Apr  7 19:47:21 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 19:47:21 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v2]
In-Reply-To: <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <ebNZEAX7tHbGLlV9SYXIZ4_fKy7qxjq9HuPLcUfomiw=.08521db0-0729-4cc1-8fac-73c531b980ce@github.com>
 <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>
 <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com>
Message-ID: <b8RxIhd2IpyY5q8RPfwTsli7JgRVcJwSXjq8-awBhfo=.6e510e1e-af54-46bb-b1fc-aee54a03ad73@github.com>

On Mon, 7 Apr 2025 18:49:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I used "internal objects" because I wanted to avoid naming concrete classes, which might or might not be used. Previous drafts mentioned BufferedReader, InputStreamReader, and CharsetDecoder.
>> 
>> I could replace "internal objects" with something more descriptive like "objects to handle buffering and charset decoding" but I'd still need a noun phrase to refer to them later. Maybe "buffering and decoding objects" ?
>
> Can we rephrase the 1st sentence to read:
> "The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters."
> 
> And remove the last "these internal objects" sentence.
> 
> And for the next paragraph, change the first line to:
> "The `readln` methods may buffer additional bytes..."
> 
> So we remove references to "internal objects."

I'm in the midst of rewriting all of this stuff. The main concern here is that applications can use System.in more or less as they please (presumably without buffering) _until_ the first call to a `readln` method, at which time _something happens_ and effectively the application cannot use System.in anymore. I'll post the revision when I've finished it.

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

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

From jlahoda at openjdk.org  Mon Apr  7 21:07:36 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 7 Apr 2025 21:07:36 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <KRfloYzR7lCutvk3DfxHhVq1NAox3AYeIs_t6328qJk=.501ab557-880b-41e0-a4db-e20579c91009@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:

  Rewrite bits about charset decoding, removing mention of "internal objects."

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/be8846e0..33e280df

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

  Stats: 27 lines in 1 file changed: 11 ins; 8 del; 8 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 smarks at openjdk.org  Mon Apr  7 21:07:36 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 7 Apr 2025 21:07:36 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: <b8RxIhd2IpyY5q8RPfwTsli7JgRVcJwSXjq8-awBhfo=.6e510e1e-af54-46bb-b1fc-aee54a03ad73@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <ebNZEAX7tHbGLlV9SYXIZ4_fKy7qxjq9HuPLcUfomiw=.08521db0-0729-4cc1-8fac-73c531b980ce@github.com>
 <909XG6FIuGBpfgkT4MB_wFynaR1MXvsnnqmdH6EYGZA=.85a20509-8d5b-4df6-a58c-fdcbf11fe596@github.com>
 <-ujytXA8SPaWsJYJCUTMKo1Bd43qrBqTeGvM3a1vF98=.ecc2c4ec-317b-4a12-9a31-68ca8a4e159a@github.com>
 <b8RxIhd2IpyY5q8RPfwTsli7JgRVcJwSXjq8-awBhfo=.6e510e1e-af54-46bb-b1fc-aee54a03ad73@github.com>
Message-ID: <tf9w1VeBSmYN3ONEf0-Wew4qQlRo4DxV53ONr41aKnI=.4105e963-ff07-4d04-b9a5-4dc854a02901@github.com>

On Mon, 7 Apr 2025 19:44:40 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Can we rephrase the 1st sentence to read:
>> "The `readln()` and `readln(String)` methods in this class decode bytes read from `System.in` into characters."
>> 
>> And remove the last "these internal objects" sentence.
>> 
>> And for the next paragraph, change the first line to:
>> "The `readln` methods may buffer additional bytes..."
>> 
>> So we remove references to "internal objects."
>
> I'm in the midst of rewriting all of this stuff. The main concern here is that applications can use System.in more or less as they please (presumably without buffering) _until_ the first call to a `readln` method, at which time _something happens_ and effectively the application cannot use System.in anymore. I'll post the revision when I've finished it.

Updated.

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

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

From jpai at openjdk.org  Tue Apr  8 01:03:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 8 Apr 2025 01:03:10 GMT
Subject: RFR: 8353332: Test jdk/jshell/ToolProviderTest.java failed in
 relation to enable-preview
In-Reply-To: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>
References: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>
Message-ID: <8jIsnLW4F-spgBvhmbsLr5LVF-aiMAdE-mc29YP-FdE=.44558a0c-bf1b-4e33-af6f-b0f0db214a40@github.com>

On Mon, 7 Apr 2025 15:44:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell keeps persisted preferences in `java.util.prefs.Preferences`. But, during tests, an empty persistence is typically used, to avoid values persisted on the test machine to affect the test.
> 
> But, in case of `jdk/jshell/ToolProviderTest.java`, this is not done, as JShell is started using the `Tool` interface.
> 
> This patch strives to fix that, by adding indirection in building JShell in `JShellToolProvider`, and using that in the test to inject empty persistence.
> 
> Thanks to @jaikiran for figuring out the probable cause.

This looks OK to me. I think it would be good to have someone more familiar with this area review this too.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24492#pullrequestreview-2748422103

From asotona at openjdk.org  Tue Apr  8 09:28:19 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 8 Apr 2025 09:28:19 GMT
Subject: RFR: 8353332: Test jdk/jshell/ToolProviderTest.java failed in
 relation to enable-preview
In-Reply-To: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>
References: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>
Message-ID: <TJFTlqYGMMWgsJAUs-WAM4xYTHMFjL8Hu-NTNkU_Cps=.2090b486-0e3a-4755-bdff-408343b8eef0@github.com>

On Mon, 7 Apr 2025 15:44:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell keeps persisted preferences in `java.util.prefs.Preferences`. But, during tests, an empty persistence is typically used, to avoid values persisted on the test machine to affect the test.
> 
> But, in case of `jdk/jshell/ToolProviderTest.java`, this is not done, as JShell is started using the `Tool` interface.
> 
> This patch strives to fix that, by adding indirection in building JShell in `JShellToolProvider`, and using that in the test to inject empty persistence.
> 
> Thanks to @jaikiran for figuring out the probable cause.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24492#pullrequestreview-2749291240

From jlahoda at openjdk.org  Tue Apr  8 09:28:19 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 8 Apr 2025 09:28:19 GMT
Subject: Integrated: 8353332: Test jdk/jshell/ToolProviderTest.java failed in
 relation to enable-preview
In-Reply-To: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>
References: <LFw_OqijYLDF4ehkCvGtGby7pwzeCwAFPcu80PaKes0=.b44c29b4-03dc-4b92-bfb3-dbcf157ab805@github.com>
Message-ID: <86gLWgfKH9zLO6uMQOsVmDpoewJ2WIOn-ZSGboAkHhA=.95ec6899-5fff-4486-bf25-1c4c684fe9a0@github.com>

On Mon, 7 Apr 2025 15:44:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JShell keeps persisted preferences in `java.util.prefs.Preferences`. But, during tests, an empty persistence is typically used, to avoid values persisted on the test machine to affect the test.
> 
> But, in case of `jdk/jshell/ToolProviderTest.java`, this is not done, as JShell is started using the `Tool` interface.
> 
> This patch strives to fix that, by adding indirection in building JShell in `JShellToolProvider`, and using that in the test to inject empty persistence.
> 
> Thanks to @jaikiran for figuring out the probable cause.

This pull request has now been integrated.

Changeset: 9088afc4
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9088afc4f16b6265e640bf176d8ca8e3ac6ca45c
Stats:     51 lines in 2 files changed: 37 ins; 1 del; 13 mod

8353332: Test jdk/jshell/ToolProviderTest.java failed in relation to enable-preview

Reviewed-by: jpai, asotona

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

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

From alanb at openjdk.org  Wed Apr  9 10:24:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:24:37 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: <KRfloYzR7lCutvk3DfxHhVq1NAox3AYeIs_t6328qJk=.501ab557-880b-41e0-a4db-e20579c91009@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <KRfloYzR7lCutvk3DfxHhVq1NAox3AYeIs_t6328qJk=.501ab557-880b-41e0-a4db-e20579c91009@github.com>
Message-ID: <3Zk9YripITF8dslVfxe4NXy91mnMLLRjqJyDk48T6l4=.6644f577-685f-4c29-9db7-311f11b8e65a@github.com>

On Mon, 7 Apr 2025 21:07:36 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:
> 
>   Rewrite bits about charset decoding, removing mention of "internal objects."

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

> 45:  * Decoding may buffer additional bytes beyond those that have been decoded to characters
> 46:  * returned to the application. After the first call to one of the {@code readln} methods,
> 47:  * any subsequent use of {@code System.in} results in unspecified behavior.

I wonder if we should add a note about mixing API usage into System.in too. There are tutorials and books that show examples build on System.in that will add buffering on that input source.

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

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

From alanb at openjdk.org  Wed Apr  9 10:39:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:39:43 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: <QJN2GI8wPOaiEsoVkXyOM7JeBKDQ42XpbkiTXJ_BhEQ=.d53f3352-7933-489e-8d76-44fb05e8754d@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
 <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>
 <fQmsn6MTmrifwu3n8449mqqV9AxQz0iFojl0qtX8PM8=.a82b535f-cd9f-4fe2-83a5-ee48219c1ed7@github.com>
 <QJN2GI8wPOaiEsoVkXyOM7JeBKDQ42XpbkiTXJ_BhEQ=.d53f3352-7933-489e-8d76-44fb05e8754d@github.com>
Message-ID: <Lk2AN3Sy2QbUkICLIwRulfJ2ZvUQ2vykzm-QXUP2JLY=.15c291b3-f7d9-4351-8365-edf6c2940e84@github.com>

On Mon, 7 Apr 2025 18:28:21 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Someone is bound to ask why the readln method throw but the println methods don't.
>
> The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason.
> 
> My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here.
> 
> UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard.
> 
> I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice.

The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.

System.in.close() would a be wild thing to do, but a case where readln would throw IOError.

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

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

From alanb at openjdk.org  Wed Apr  9 10:49:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 10:49:34 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: <KRfloYzR7lCutvk3DfxHhVq1NAox3AYeIs_t6328qJk=.501ab557-880b-41e0-a4db-e20579c91009@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <KRfloYzR7lCutvk3DfxHhVq1NAox3AYeIs_t6328qJk=.501ab557-880b-41e0-a4db-e20579c91009@github.com>
Message-ID: <sRnDTMdHzW1_OhXig0Jp6fZ4eyBygSZRwSrVfKdYeQw=.8d8a2e93-04ee-4353-84fd-087d46bc2e4c@github.com>

On Mon, 7 Apr 2025 21:07:36 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:
> 
>   Rewrite bits about charset decoding, removing mention of "internal objects."

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

> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,
> 42:  * or if the charset it names cannot be loaded, then UTF-8 is used instead.

stdout.encoding and stdin.encoding are specified (in System.getProperties) to lead to unspecified behavior if started with either property set to a value other than UTF-8. We should work through the issues of introducing stdin.encoding as soon as we can, esp. the redirect cases and whether there is use cases for setting any of these properties on the command line.

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

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

From ihse at openjdk.org  Wed Apr  9 15:09:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:09:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:

> 20: # Peter Smolik
> 21: Cp1250 WINDOWS-1250 0x00FF
> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)

This does not seem to have been a correct conversion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2035582242

From acobbs at openjdk.org  Wed Apr  9 15:50:48 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 15:50:48 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
Message-ID: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>

This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 

There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.

First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.

Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.

Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

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

Commit messages:
 - Small cleanups relating to Log.DiagnosticHandler.

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

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

From smarks at openjdk.org  Wed Apr  9 16:57:40 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 9 Apr 2025 16:57:40 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: <sRnDTMdHzW1_OhXig0Jp6fZ4eyBygSZRwSrVfKdYeQw=.8d8a2e93-04ee-4353-84fd-087d46bc2e4c@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <KRfloYzR7lCutvk3DfxHhVq1NAox3AYeIs_t6328qJk=.501ab557-880b-41e0-a4db-e20579c91009@github.com>
 <sRnDTMdHzW1_OhXig0Jp6fZ4eyBygSZRwSrVfKdYeQw=.8d8a2e93-04ee-4353-84fd-087d46bc2e4c@github.com>
Message-ID: <f5blh_twGobPtycWbSY8Fto47MAz_3xOvmXr70ouSLI=.6fb0e88d-32b1-4f4f-9512-32433fc786ef@github.com>

On Wed, 9 Apr 2025 10:46:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rewrite bits about charset decoding, removing mention of "internal objects."
>
> src/java.base/share/classes/java/lang/IO.java line 42:
> 
>> 40:  * {@code System.in} into characters. The charset used for decoding is specified by the
>> 41:  * {@link System#getProperties stdin.encoding} property. If this property is not present,
>> 42:  * or if the charset it names cannot be loaded, then UTF-8 is used instead.
> 
> stdout.encoding and stderr.encoding are specified (in System.getProperties) to lead to unspecified behavior if started with either property set to a value other than UTF-8. We should work through the issues of introducing stdin.encoding as soon as we can, esp. the redirect cases and whether there is use cases for setting any of these properties on the command line.

Yes, believe it or not, I am still studying this...

> src/java.base/share/classes/java/lang/IO.java line 47:
> 
>> 45:  * Decoding may buffer additional bytes beyond those that have been decoded to characters
>> 46:  * returned to the application. After the first call to one of the {@code readln} methods,
>> 47:  * any subsequent use of {@code System.in} results in unspecified behavior.
> 
> I wonder if we should add a note about mixing API usage into System.in too. There are tutorials and books that show examples build on System.in that will add buffering on that input source.

Might be a good idea. I'll handle this separately. I don't want it to refer to a Preview API. I'll probably just use Scanner and InputStreamReader as examples.

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

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

From smarks at openjdk.org  Wed Apr  9 17:05:38 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 9 Apr 2025 17:05:38 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v3]
In-Reply-To: <Lk2AN3Sy2QbUkICLIwRulfJ2ZvUQ2vykzm-QXUP2JLY=.15c291b3-f7d9-4351-8365-edf6c2940e84@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
 <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>
 <fQmsn6MTmrifwu3n8449mqqV9AxQz0iFojl0qtX8PM8=.a82b535f-cd9f-4fe2-83a5-ee48219c1ed7@github.com>
 <QJN2GI8wPOaiEsoVkXyOM7JeBKDQ42XpbkiTXJ_BhEQ=.d53f3352-7933-489e-8d76-44fb05e8754d@github.com>
 <Lk2AN3Sy2QbUkICLIwRulfJ2ZvUQ2vykzm-QXUP2JLY=.15c291b3-f7d9-4351-8365-edf6c2940e84@github.com>
Message-ID: <PxkUoAdfTR7fJ1TD4bgMnpUO3gcggluc5aM5du8jjKY=.43cbc286-6132-40be-9820-427ab5ef8501@github.com>

On Wed, 9 Apr 2025 10:36:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The IOError was carried over from Console.readLine(), which throws IOError on error. Of course we're decoupled from Console now, but that was the original reason.
>> 
>> My guess is that Console methods throw IOError because (a) they didn't want to make everybody catch IOException, (b) they didn't want to maintain an internal error state like PrintStream, and (c) they wanted to throw a throwable whose type conveyed the meaning that it wasn't expected to be handled. IOError and Console were both added in JDK 1.6. Maybe that reasoning still applies here.
>> 
>> UncheckedIOException wasn't added until JDK 1.8. Note also that UncheckedIOException has a cause of IOException, so it can't arise from some other throwable. This was used in the previous implementation, where IOError was thrown if Console was null. That doesn't apply anymore, but IOError is still somewhat more flexible than UncheckedIOException in this regard.
>> 
>> I think we need to say something, implicitly or explicitly, about error handling. Note that PrintStream has this internal error state so output is covered already. For input it seems like IOError is reasonable, but maybe there's a better choice.
>
> The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.
> 
> System.in.close() would a be wild thing to do, but a case where readln would throw IOError.

Ah. Does the specification here need to state the policy around malformed input and unmappable characters? (Or, maybe in the class specification.)

People have ended up in cases where System.in is closed. It can occur when combining use of Scanner to read from System.in and applying the anything-that-you-open-must-be-closed rule, e.g.,

    try (Scanner sc = new Scanner(System.in)) {
        String s = sc.nextLine();
    }

which is a mistake, but it takes a long time to explain....

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

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

From mcimadamore at openjdk.org  Wed Apr  9 17:29:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Apr 2025 17:29:45 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
Message-ID: <SRP282MgFLKlZcFM7dYqceAcBMovMVgAfZqAHktjBvg=.377fc17e-8afb-45f4-b5b5-5996494028bb@github.com>

On Wed, 9 Apr 2025 15:45:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
> 
> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
> 
> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
> 
> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
> 
> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 184:

> 182:         /** Report all deferred diagnostics in the specified order. */
> 183:         public void reportDeferredDiagnostics(Comparator<JCDiagnostic> order) {
> 184:             deferred.sort(order);

So, here there would seem to be a difference in behavior, in that `sort` has a permanent side-effect on `deferred`. But I think this is fine, because at the end of this method we end up setting `deferred = null` anyway, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24553#discussion_r2035817640

From acobbs at openjdk.org  Wed Apr  9 17:40:47 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 9 Apr 2025 17:40:47 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: <SRP282MgFLKlZcFM7dYqceAcBMovMVgAfZqAHktjBvg=.377fc17e-8afb-45f4-b5b5-5996494028bb@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
 <SRP282MgFLKlZcFM7dYqceAcBMovMVgAfZqAHktjBvg=.377fc17e-8afb-45f4-b5b5-5996494028bb@github.com>
Message-ID: <tch515AMhsb2oHq73hEbr5dr1d9dmxtGT2TZBQha3FI=.81e42c64-aac9-4316-9bff-25df270359d4@github.com>

On Wed, 9 Apr 2025 17:26:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
>> 
>> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
>> 
>> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
>> 
>> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
>> 
>> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 184:
> 
>> 182:         /** Report all deferred diagnostics in the specified order. */
>> 183:         public void reportDeferredDiagnostics(Comparator<JCDiagnostic> order) {
>> 184:             deferred.sort(order);
> 
> So, here there would seem to be a difference in behavior, in that `sort` has a permanent side-effect on `deferred`. But I think this is fine, because at the end of this method we end up setting `deferred = null` anyway, right?

Yes, that's my thought too - we are indeed changing the list, but who cares because we're about to discard it. Of course the discarding is done indirectly by `reportDeferredDiagnostics()`, not by this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24553#discussion_r2035834713

From alanb at openjdk.org  Wed Apr  9 17:55:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 17:55:47 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v4]
In-Reply-To: <BZ0t27h2QH3LJtwIz8A4iY2A4BAM9vNxqZobc188_Jo=.a9493884-df0e-4fe3-8319-3d7db6b5d619@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
 <BZ0t27h2QH3LJtwIz8A4iY2A4BAM9vNxqZobc188_Jo=.a9493884-df0e-4fe3-8319-3d7db6b5d619@github.com>
Message-ID: <PbysiHJPMv0YdYiU7BPZqrJsqm0Xbo2Tc40e3NZhyOM=.2e7fa660-83c6-439b-a5f8-5c031cf075c1@github.com>

On Wed, 2 Apr 2025 16:59:16 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
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - avoiding hardcoded constants.

src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 415:

> 413:                 if (major >= 54
> 414:                     && mods.contains(Requires.Modifier.STATIC)) {
> 415:                     String flagName = "ACC_STATIC_PHASE";

A minor comment on the style here, do you mind combin L413+414 as it will make it easier to read. The change is okay of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2035855402

From jlu at openjdk.org  Wed Apr  9 21:28:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Apr 2025 21:28:41 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
Message-ID: <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>

On Wed, 9 Apr 2025 15:06:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Convert the merged master changes to UTF-8
>>  - Merge master and fix conflicts
>>  - Close streams when finished loading into props
>>  - Adjust CF test to read in with UTF-8 to fix failing test
>>  - Reconvert CS.properties to UTF-8
>>  - Revert all changes to CurrencySymbols.properties
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
> 
>> 20: # Peter Smolik
>> 21: Cp1250 WINDOWS-1250 0x00FF
>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
> 
> This does not seem to have been a correct conversion.

Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)

Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036165417

From jlahoda at openjdk.org  Thu Apr 10 01:03:01 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 01:03:01 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
Message-ID: <IZrqcv-JIMs1a8hTD7Jjm3d194sjnmoGCPk0jFNSe88=.c25de08b-c634-406a-afa2-f9c66f188b91@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:

  Add clause about handling of malformed/unmappable bytes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24438/files
  - new: https://git.openjdk.org/jdk/pull/24438/files/33e280df..05cc336e

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

  Stats: 3 lines in 1 file changed: 2 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 smarks at openjdk.org  Thu Apr 10 01:06:43 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 10 Apr 2025 01:06:43 GMT
Subject: RFR: 8344706: Compiler Implementation of Compact Source Files and
 Instance Main Methods [v4]
In-Reply-To: <PxkUoAdfTR7fJ1TD4bgMnpUO3gcggluc5aM5du8jjKY=.43cbc286-6132-40be-9820-427ab5ef8501@github.com>
References: <t11qUa9QfPgsL81JSmuMT-myzfLOrksD8zkPmWNOCM0=.e24b27ab-7b7b-4a81-b031-a037631dca29@github.com>
 <cI_vZ2mHteOcZLrgqbL-flUET62OTYhu6JJHaJi5vwg=.bcdff18f-d613-4838-b8f3-2955e01a9d08@github.com>
 <HB-WVblsRoK2aDJJoIX0OfOZWFfljSLrkRjOQPMnabU=.14174744-821a-41a7-8487-00bbff852b90@github.com>
 <fQmsn6MTmrifwu3n8449mqqV9AxQz0iFojl0qtX8PM8=.a82b535f-cd9f-4fe2-83a5-ee48219c1ed7@github.com>
 <QJN2GI8wPOaiEsoVkXyOM7JeBKDQ42XpbkiTXJ_BhEQ=.d53f3352-7933-489e-8d76-44fb05e8754d@github.com>
 <Lk2AN3Sy2QbUkICLIwRulfJ2ZvUQ2vykzm-QXUP2JLY=.15c291b3-f7d9-4351-8365-edf6c2940e84@github.com>
 <PxkUoAdfTR7fJ1TD4bgMnpUO3gcggluc5aM5du8jjKY=.43cbc286-6132-40be-9820-427ab5ef8501@github.com>
Message-ID: <2WoKJPTnP6NRxytTHtqJoi_8b-gAT1vd3YgO2swg_9U=.69c3746e-97cc-485e-8742-b92c1fbc4367@github.com>

On Wed, 9 Apr 2025 17:02:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The readln methods handle malformed-input and unmappable-character errors by dropping, and using a replacement value. So erroneous input doesn't throw IOError with a CharacterCodingException as the cause.
>> 
>> System.in.close() would a be wild thing to do, but a case where readln would throw IOError.
>
> Ah. Does the specification here need to state the policy around malformed input and unmappable characters? (Or, maybe in the class specification.)
> 
> People have ended up in cases where System.in is closed. It can occur when combining use of Scanner to read from System.in and applying the anything-that-you-open-must-be-closed rule, e.g.,
> 
>     try (Scanner sc = new Scanner(System.in)) {
>         String s = sc.nextLine();
>     }
> 
> which is a mistake, but it takes a long time to explain....

I added a clause to the class specification that covers malformed/unmappable byte sequences.

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

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

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
Message-ID: <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>

On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
>> 
>>> 20: # Peter Smolik
>>> 21: Cp1250 WINDOWS-1250 0x00FF
>>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
>> 
>> This does not seem to have been a correct conversion.
>
> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
> 
> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.

You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036695622

From ihse at openjdk.org  Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
Message-ID: <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>

On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
>> 
>> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.
>
> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.

If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036696723

From eirbjo at openjdk.org  Thu Apr 10 08:10:42 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:10:42 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
 <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
Message-ID: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>

On Thu, 10 Apr 2025 07:32:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.
>
> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.

Some observations: 

1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?

2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.

3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`

4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:


byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
String decoded = new String(origBytes, StandardCharsets.UTF_8);
byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
String hex = HexFormat.of().formatHex(encoded);
assertEquals("efbfbd", hex);
``` 

Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036767319

From ihse at openjdk.org  Thu Apr 10 08:38:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:38:38 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
 <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
 <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
 <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
 <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
 <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
Message-ID: <qG3Fpev16BBWYvs2zSE5CeqmTcfRF4h_l-PAM3PVHns=.4a1e25de-c3e2-4876-a8e5-c3f32cfef4c1@github.com>

On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.
>
> Some observations: 
> 
> 1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?
> 
> 2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.
> 
> 3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`
> 
> 4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:
> 
> 
> byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
> String decoded = new String(origBytes, StandardCharsets.UTF_8);
> byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
> String hex = HexFormat.of().formatHex(encoded);
> assertEquals("efbfbd", hex);
> ``` 
> 
> Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.

> This PR seems to have been abondoned, so perhaps this discussion belongs in https://github.com/openjdk/jdk/pull/15694 ?

Oh, I didn't notice this was supplanted by another PR. It might be better to continue there, yes. Even if closed PRs seldom are the best places to conduct discussions, I think it might be a good idea to scrutinize all files modified by this script.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036820765

From ihse at openjdk.org  Thu Apr 10 08:41:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:41:45 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <yO1q1NVjOInbzcWCkJra3sYGkfv3OBhg__dKO0w--s0=.d7a4b185-6ed1-4ae6-bdfe-01b3204da46a@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Continuing the discussion that was started at a predecessor to this PR, https://github.com/openjdk/jdk/pull/12726#discussion_r2035582242. At least one incorrect conversion has been found in this PR. It might be worthwhile to double- and triple-check all the other conversions as well.

As part of https://bugs.openjdk.org/browse/JDK-8301971 I am trying various ways of detecting files without UTF-8 encoding, but it is still a bit of hit and miss, since there are no surefire way of telling which encoding a file has, only heuristics. So finding and following up potential sources of error is important.

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791991649
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791997157

From eirbjo at openjdk.org  Thu Apr 10 08:48:37 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:48:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

FWIW, I checked out the revision of the commit previous to this change and found the following:


% git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
% find src -name "*.properties" | xargs file | grep -v ASCII
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
  ISO-8859 text
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
  Unicode text, UTF-8 text, with very long lines (322)


Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792014164

From ihse at openjdk.org  Thu Apr 10 09:45:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 09:45:56 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <GlAmyjF3ZmTQHUhkTXRmmrijCWM_4JoredRJOuyVyIc=.775fbc8d-80da-4b0b-b2e1-e5b7e75b3d52@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Thanks for checking!

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792170460

From mcimadamore at openjdk.org  Thu Apr 10 14:09:45 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 14:09:45 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
Message-ID: <4h5UCyj1741PhAs78B3mslLLBTeR-I-1tiqF0jY8FhA=.6f1ab892-1893-498b-ba4a-21d5228f5e65@github.com>

On Wed, 9 Apr 2025 15:45:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
> 
> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
> 
> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
> 
> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
> 
> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24553#pullrequestreview-2756989330

From mcimadamore at openjdk.org  Thu Apr 10 14:09:46 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 14:09:46 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: <tch515AMhsb2oHq73hEbr5dr1d9dmxtGT2TZBQha3FI=.81e42c64-aac9-4316-9bff-25df270359d4@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
 <SRP282MgFLKlZcFM7dYqceAcBMovMVgAfZqAHktjBvg=.377fc17e-8afb-45f4-b5b5-5996494028bb@github.com>
 <tch515AMhsb2oHq73hEbr5dr1d9dmxtGT2TZBQha3FI=.81e42c64-aac9-4316-9bff-25df270359d4@github.com>
Message-ID: <psI737aOMUjJ0PDKg6QoDO5zDad87dwtmPMslTc3eHc=.45c18611-fa40-4874-a726-5d9f4531995a@github.com>

On Wed, 9 Apr 2025 17:38:10 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java line 184:
>> 
>>> 182:         /** Report all deferred diagnostics in the specified order. */
>>> 183:         public void reportDeferredDiagnostics(Comparator<JCDiagnostic> order) {
>>> 184:             deferred.sort(order);
>> 
>> So, here there would seem to be a difference in behavior, in that `sort` has a permanent side-effect on `deferred`. But I think this is fine, because at the end of this method we end up setting `deferred = null` anyway, right?
>
> Yes, that's my thought too - we are indeed changing the list, but who cares because we're about to discard it. Of course the discarding is done indirectly by `reportDeferredDiagnostics()`, not by this method.

As usual -- maybe add comments to capture this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24553#discussion_r2037512331

From acobbs at openjdk.org  Thu Apr 10 14:31:10 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 14:31:10 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
 [v2]
In-Reply-To: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
Message-ID: <ZdSUc_7dWUc7v4MxxaxHnmjFa7jsNtsptYM1YrsIgBs=.496d4837-cc17-4468-8760-d7382dcca780@github.com>

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
> 
> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
> 
> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
> 
> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
> 
> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

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

  Add comment per review suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24553/files
  - new: https://git.openjdk.org/jdk/pull/24553/files/2e68d7a3..dc3b98c2

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

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

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

From acobbs at openjdk.org  Thu Apr 10 14:31:10 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 14:31:10 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
 [v2]
In-Reply-To: <psI737aOMUjJ0PDKg6QoDO5zDad87dwtmPMslTc3eHc=.45c18611-fa40-4874-a726-5d9f4531995a@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
 <SRP282MgFLKlZcFM7dYqceAcBMovMVgAfZqAHktjBvg=.377fc17e-8afb-45f4-b5b5-5996494028bb@github.com>
 <tch515AMhsb2oHq73hEbr5dr1d9dmxtGT2TZBQha3FI=.81e42c64-aac9-4316-9bff-25df270359d4@github.com>
 <psI737aOMUjJ0PDKg6QoDO5zDad87dwtmPMslTc3eHc=.45c18611-fa40-4874-a726-5d9f4531995a@github.com>
Message-ID: <mf_1lATLOvdvXCm8gF4TAUWtBLjL3NIQER6raiX3GsY=.948469f3-2f9f-445e-ab6f-49ccac3ba235@github.com>

On Thu, 10 Apr 2025 14:06:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yes, that's my thought too - we are indeed changing the list, but who cares because we're about to discard it. Of course the discarding is done indirectly by `reportDeferredDiagnostics()`, not by this method.
>
> As usual -- maybe add comments to capture this

Done in dc3b98c2685 - thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24553#discussion_r2037557820

From mcimadamore at openjdk.org  Thu Apr 10 15:00:44 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Apr 2025 15:00:44 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
 [v2]
In-Reply-To: <ZdSUc_7dWUc7v4MxxaxHnmjFa7jsNtsptYM1YrsIgBs=.496d4837-cc17-4468-8760-d7382dcca780@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
 <ZdSUc_7dWUc7v4MxxaxHnmjFa7jsNtsptYM1YrsIgBs=.496d4837-cc17-4468-8760-d7382dcca780@github.com>
Message-ID: <olK7jKbvGCcDTWnUSTnM1naTjkUKBi735b55ueC2P5Q=.61ae90eb-e619-4e47-ac71-d72f943a6c95@github.com>

On Thu, 10 Apr 2025 14:31:10 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
>> 
>> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
>> 
>> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
>> 
>> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
>> 
>> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment per review suggestion.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24553#pullrequestreview-2757189892

From liach at openjdk.org  Thu Apr 10 18:01:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Apr 2025 18:01:57 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v57]
In-Reply-To: <uQ8FmRZ1dc9iWSbVqOOigL7x4AQbgUcwzpGFfR2jfg4=.1ede3b61-86e9-434c-b84c-8e87dfe6378e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <M06P1ym-MnvjB2Z-v9hfGFjXV2RbBeIqg0EMzWr9LNU=.b363d892-f5da-42dc-b53d-7a9a0ed1689e@github.com>
 <uQ8FmRZ1dc9iWSbVqOOigL7x4AQbgUcwzpGFfR2jfg4=.1ede3b61-86e9-434c-b84c-8e87dfe6378e@github.com>
Message-ID: <17CDLKZYKCAtHgc4vB-Y9o1k266gkM4Sy7ZrmUfsjvU=.9328b2a1-36bd-45c8-beab-3b984fb65762@github.com>

On Sun, 6 Apr 2025 10:50:50 GMT, Luca Kellermann <duke at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Update summary in ExactnessConversionsSupportTest
>>  - Address review by Jan
>>  - Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
>>  - Small fix in Javadoc
>>  - Tidy up Javadoc of Lower.visitTypeTest
>>  - Tidy up Javadoc of IllegalArgumentException in typeSwitch
>>  - Improve readability in SwitchBootstraps
>>  - Update year
>>  - Cleanup redundant clone
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 676:
> 
>> 674:         }
>> 675:         else if (selectorType.equals(targetType) ||
>> 676:                 ((selectorType.equals(byte.class) && !targetType.equals(char.class)) ||
> 
> Suggestion:
> 
>                 ((selectorType.equals(byte.class) && targetType.isPrimitve() && !targetType.equals(boolean.class) && !targetType.equals(char.class)) ||
> 
> Otherwise, `SwitchBootstraps.typeSwitch` produces wrong results for `byte`:
> 
> var l = MethodHandles.lookup();
> var shortType = MethodType.methodType(int.class, short.class, int.class);
> var byteType = MethodType.methodType(int.class, byte.class, int.class);
> 
> CallSite shortSwitch = SwitchBootstraps.typeSwitch(l, "", shortType, String.class);
> CallSite byteSwitch = SwitchBootstraps.typeSwitch(l, "", byteType, String.class);
> 
> int shortIndex = (int) shortSwitch.getTarget().invokeExact((short) 1, 0);
> int byteIndex = (int) byteSwitch.getTarget().invokeExact((byte) 1, 0);
> 
> System.out.println(shortIndex == 1); // true
> System.out.println(byteIndex == 1); // false
> System.out.println(byteIndex); // 0
> 
> This would cause this code to misbehave (if it would compile, which it doesn't):
> 
> byte b = 1;
> switch (b) {
>     case String s -> System.out.println("How did we get here? byte is " + s.getClass());
> }
> 
> So it isn't really a problem with `javac` but could cause problems for other users of `SwitchBootstraps`.

A JBS issue has been created at https://bugs.openjdk.org/browse/JDK-8354323

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r2037974588

From jlahoda at openjdk.org  Thu Apr 10 18:04:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 18:04:54 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v5]
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <V4boUc9CMj-T6zZhhCuAZLU7w_vdukRUSht5KbRWVW8=.fa570455-ff3e-49ad-a3b4-22b9fe011577@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:

  Reflecting review feedback: cleanup formatting in ModuleInfo.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/d66703c1..029e0dd5

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

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 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  Thu Apr 10 18:04:54 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 10 Apr 2025 18:04:54 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v4]
In-Reply-To: <PbysiHJPMv0YdYiU7BPZqrJsqm0Xbo2Tc40e3NZhyOM=.2e7fa660-83c6-439b-a5f8-5c031cf075c1@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
 <BZ0t27h2QH3LJtwIz8A4iY2A4BAM9vNxqZobc188_Jo=.a9493884-df0e-4fe3-8319-3d7db6b5d619@github.com>
 <PbysiHJPMv0YdYiU7BPZqrJsqm0Xbo2Tc40e3NZhyOM=.2e7fa660-83c6-439b-a5f8-5c031cf075c1@github.com>
Message-ID: <wi0Q_ZRp-igTOrBcYnY7IK_MSYXAHoyk4Vnqa_4SfPU=.88e44510-aa82-4f1d-bb02-641e5c8ffe46@github.com>

On Wed, 9 Apr 2025 17:52:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback - avoiding hardcoded constants.
>
> src/java.base/share/classes/jdk/internal/module/ModuleInfo.java line 415:
> 
>> 413:                 if (major >= 54
>> 414:                     && mods.contains(Requires.Modifier.STATIC)) {
>> 415:                     String flagName = "ACC_STATIC_PHASE";
> 
> A minor comment on the style here, do you mind combin L413+414 as it will make it easier to read. The change is okay of course.

I did this:
https://github.com/openjdk/jdk/pull/23801/commits/029e0dd59c7160f4fe043dd7191860b067ca787c
Please let me know if something more/different is needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23801#discussion_r2037978491

From alanb at openjdk.org  Thu Apr 10 18:30:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 10 Apr 2025 18:30:36 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v5]
In-Reply-To: <V4boUc9CMj-T6zZhhCuAZLU7w_vdukRUSht5KbRWVW8=.fa570455-ff3e-49ad-a3b4-22b9fe011577@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
 <V4boUc9CMj-T6zZhhCuAZLU7w_vdukRUSht5KbRWVW8=.fa570455-ff3e-49ad-a3b4-22b9fe011577@github.com>
Message-ID: <jJcuo22rZAS1e171waw15oAgs9TCaYarACU2pO8kwY4=.9d0fb1bf-e4e4-4624-bb54-51253ec63591@github.com>

On Thu, 10 Apr 2025 18:04:54 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
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback: cleanup formatting in ModuleInfo.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2757854063

From jlu at openjdk.org  Thu Apr 10 18:47:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Apr 2025 18:47:53 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
Message-ID: <9aQcWun5KNgHgELVwkc3478_RtqfhRL1Cxvyn2Yl0Nw=.07ee596f-e738-4796-8d27-14621ed8860c@github.com>

On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> FWIW, I checked out the revision of the commit previous to this change and found the following:
> 
> 
> % git checkout b55e418a077791b39992042411cde97f68dc39fe^ 
> % find src -name "*.properties" | xargs file | grep -v ASCII
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties: 
>   ISO-8859 text
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
>   Unicode text, UTF-8 text, with very long lines (322)
> 
> 
> Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.

This conversion was performed under the assumption of ASCII set and Unicode escape sequences, which is the format we expect for the translation process for .properties files. That file should have been omitted from this change. Thank you @eirbjo and @magicus for the analysis and checking!

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2794828598

From acobbs at openjdk.org  Thu Apr 10 20:36:37 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 20:36:37 GMT
Subject: RFR: 8354216: Small cleanups relating to Log.DiagnosticHandler
 [v2]
In-Reply-To: <ZdSUc_7dWUc7v4MxxaxHnmjFa7jsNtsptYM1YrsIgBs=.496d4837-cc17-4468-8760-d7382dcca780@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
 <ZdSUc_7dWUc7v4MxxaxHnmjFa7jsNtsptYM1YrsIgBs=.496d4837-cc17-4468-8760-d7382dcca780@github.com>
Message-ID: <y46AI5nbnmdjfWr4A5OSRXcbRamkyUUT-adfEjfiGpA=.5e36a509-a170-4679-b313-d6fe211c04fe@github.com>

On Thu, 10 Apr 2025 14:31:10 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
>> 
>> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
>> 
>> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
>> 
>> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
>> 
>> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment per review suggestion.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/24553#issuecomment-2795096193

From acobbs at openjdk.org  Thu Apr 10 20:36:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 10 Apr 2025 20:36:38 GMT
Subject: Integrated: 8354216: Small cleanups relating to Log.DiagnosticHandler
In-Reply-To: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
References: <HfN5yxpupzJ7CUmOe28X2MuvwYm2HCdbBJLIn8BfJI4=.0beeeab0-9b12-4340-8732-973a30b74121@github.com>
Message-ID: <nT7R3zqklg1Nf4N297NupIl45OR5Qbp70olYpUSlsEw=.85c921ff-9e89-471c-87de-2758ebbb1b07@github.com>

On Wed, 9 Apr 2025 15:45:23 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This is split off as a sub-task of [JDK-8224228](https://bugs.openjdk.org/browse/JDK-8224228), which seeks to add `@SuppressWarnings` support for lexical features. 
> 
> There are a few of small refactoring cleanups possible relating to the nested class `Log.DiagnosticHandler`.
> 
> First, this class is currently declared as a static inner class with an explicit field reference to its outer class (`Log`) instance. Although protected and non final, this field really should never be changed. Therefore, there is no reason not to just make `DiagnosticHandler` a non-static inner class. This will slightly simplify the code and eliminate an obscure corner case by which a bug could possibly occur someday.
> 
> Secondly, the deferred diagnostics are currently stored in a linked list, and in cases where they must be sorted before being reported, they have to be copied into an array first. A simpler and more space efficient approach would be to just use an `ArrayList`. Then the sorting variant of the method can just sort the list in place and delegate directly to the non-sorting variant.
> 
> Finally, the code can be simplified by replacing a null `filter` predicate with an always true predicate at construction time instead of at filter time.

This pull request has now been integrated.

Changeset: 4890b74c
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4890b74c048a1472b87687294c316ecfb324e4ba
Stats:     85 lines in 11 files changed: 8 ins; 26 del; 51 mod

8354216: Small cleanups relating to Log.DiagnosticHandler

Reviewed-by: mcimadamore

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

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

From jlahoda at openjdk.org  Fri Apr 11 11:20:30 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 11 Apr 2025 11:20:30 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v6]
In-Reply-To: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
Message-ID: <AWP2vROpH7zQ0Pev5DRQdpzhwri5OgST3uCnJeC_Xsc=.198c4b5c-cbcd-4cc5-9a59-27e366f8aec1@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Adjusting ToolProviderTest to the updated persistence handling.
 - Merge branch 'master' into JDK-8344708
 - Reflecting review feedback: cleanup formatting in ModuleInfo.
 - Reflecting review feedback - avoiding hardcoded constants.
 - Fixing test.
 - 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.
 - Cleanup.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/124c1cf4...4c14c3b0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23801/files
  - new: https://git.openjdk.org/jdk/pull/23801/files/029e0dd5..4c14c3b0

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

  Stats: 213792 lines in 4489 files changed: 97109 ins; 91547 del; 25136 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 vromero at openjdk.org  Fri Apr 11 15:19:31 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 11 Apr 2025 15:19:31 GMT
Subject: RFR: 8344708: Compiler Implementation of Module Import
 Declarations [v6]
In-Reply-To: <AWP2vROpH7zQ0Pev5DRQdpzhwri5OgST3uCnJeC_Xsc=.198c4b5c-cbcd-4cc5-9a59-27e366f8aec1@github.com>
References: <amvWsq1XvrOLMMtqqOFwhKZeh0IKN3vlqXpxbFv1J2M=.1292061d-fdfd-43cf-a4de-cb30a4ee1be0@github.com>
 <AWP2vROpH7zQ0Pev5DRQdpzhwri5OgST3uCnJeC_Xsc=.198c4b5c-cbcd-4cc5-9a59-27e366f8aec1@github.com>
Message-ID: <qfjR4SsXRmotK-yVdNtMPIN7bBjhxoN0eETDJNmBtpA=.c77dd923-d133-41be-9db3-7abdc15257be@github.com>

On Fri, 11 Apr 2025 11:20:30 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
>
> 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 12 additional commits since the last revision:
> 
>  - Adjusting ToolProviderTest to the updated persistence handling.
>  - Merge branch 'master' into JDK-8344708
>  - Reflecting review feedback: cleanup formatting in ModuleInfo.
>  - Reflecting review feedback - avoiding hardcoded constants.
>  - Fixing test.
>  - 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.
>  - Cleanup.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/950110ae...4c14c3b0

lg

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23801#pullrequestreview-2760679225

From davidalayachew at gmail.com  Sat Apr 12 14:39:22 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 12 Apr 2025 10:39:22 -0400
Subject: My experience using Java to do CLI Scripting
Message-ID: <CAA9v-_PQfZhtuaY8WsC=ekazd6gA7_p83Vah=q3vyugzx9dySg@mail.gmail.com>

Hello Amber Dev Team and Kulla Dev Team,

(I made a reddit post too, if you prefer to interact there instead --
https://www.reddit.com/r/java/comments/1jx87ys/)

The following JEP's have released recently.

   - JEP 495: Simple Source Files and Instance Main Methods
   <https://openjdk.org/jeps/495>
   - JEP 330: Launch Single-File Source-Code Programs
   <https://openjdk.org/jeps/330>
   - JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
   <https://openjdk.org/jeps/222>

These have made it really easy for me to do CLI scripting in Java, as
opposed to Bash. However, I've run into some pain points, as I've relied
more and more on Java.

For starters, the hand off from Java --> Bash is kind of ugly. Bash -->
Java is not bad, due to void main(final String[] args), as well as Bash's
xargs. But Java --> Bash is ugly, and here is an example demonstrating
how/why.
------------------------------

I use AWS CLI to manage my dev environment. It's super powerful, and is all
available directly from the CLI, using simple Bash or even CMD.

Let's say I use AWS CLI to gather some ad-hoc information about my entire
dev environment. How do I manage the multiple handoffs back and forth
between AWS CLI and Java?

There are no good answers.

   1. Store the results into a file, then use JShell/java(c) to process the
   output file from Bash/AWS CLI.
      - There's multiple handoffs back and forth between AWS CLI and Java.
      So, every handoff from Java ---> AWS CLI means generating a new
file, thus
      increasing the complexity and cruft. It's unideal.
   2. Use Java's ProcessBuilder
   <https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/ProcessBuilder.html>
   and Process
   <https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/Process.html>
   classes.
      - This works, but is heavy-handed. Look at the examples in those
      links. That is multiple lines of code to represent a single bash command.
      It does appear to be the idiomatic way, though.
   3. Do all upstream processing with AWS CLI in Bash directly, then do
   only a single handoff to Java, once I have done all I need to with AWS CLI.
      - This is definitely the least painful, but it also means I don't use
      much Java at all. And any changes in upstream processing must be done in
      Bash to avoid handoff headaches from AWS CLI ---> Java.
   4. Download the AWS SDK Jar files and just do it all in Java.
      - Ignoring the fact that some things are much harder to do via the
      AWS Java SDK's, there's actually some functionality that just isn't
      available via the Java ones. I'd have to recreate it myself, and it would
      be a significant lift.

Option 4 is best when I am building an application, but for ad-hoc checks
that I want to do on the fly (my most common use-case by far), I have been
using Option 3.

I just wish I could use more Java. It's a *FAR BETTER*tool than Bash, but I
can't justify the level of effort for ad-hoc use cases because of the poor
hand off from Java --> Bash. And since AWS CLI is only available via
Bash/CMD, I'm stuck with a bunch of not-good choices.
------------------------------

CLI Scripting in Java is great, but I wanted to highlight this pain point
to spread awareness.

Can you relate?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250412/a3e476ab/attachment-0001.htm>

From ron.pressler at oracle.com  Sat Apr 12 15:02:05 2025
From: ron.pressler at oracle.com (Ron Pressler)
Date: Sat, 12 Apr 2025 15:02:05 +0000
Subject: My experience using Java to do CLI Scripting
In-Reply-To: <CAA9v-_PQfZhtuaY8WsC=ekazd6gA7_p83Vah=q3vyugzx9dySg@mail.gmail.com>
References: <CAA9v-_PQfZhtuaY8WsC=ekazd6gA7_p83Vah=q3vyugzx9dySg@mail.gmail.com>
Message-ID: <356624F4-6FE4-4D22-92EE-049C1E03472C@oracle.com>

Hi.

Let?s focus on ProcessBuilder and Process (as I think that?s where you want to focus, and why I think this discussion is more appropriate for core-libs-dev). Can you try to show more concretely what the pain point is in your actual code?

The ProcessBuilder example is long because it does multiple things, each of which may or may not be relevant to your use case. That doing five different things requires five lines of code doesn?t help us see where your specific pain point is.

? Ron

> On 12 Apr 2025, at 15:39, David Alayachew <davidalayachew at gmail.com> wrote:
> 
> Hello Amber Dev Team and Kulla Dev Team,
> 
> (I made a reddit post too, if you prefer to interact there instead -- https://www.reddit.com/r/java/comments/1jx87ys/)
> The following JEP's have released recently.
>     ? JEP 495: Simple Source Files and Instance Main Methods
>     ? JEP 330: Launch Single-File Source-Code Programs
>     ? JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)
> These have made it really easy for me to do CLI scripting in Java, as opposed to Bash. However, I've run into some pain points, as I've relied more and more on Java.
> For starters, the hand off from Java --> Bash is kind of ugly. Bash --> Java is not bad, due to void main(final String[] args), as well as Bash's xargs. But Java --> Bash is ugly, and here is an example demonstrating how/why.
> I use AWS CLI to manage my dev environment. It's super powerful, and is all available directly from the CLI, using simple Bash or even CMD.
> Let's say I use AWS CLI to gather some ad-hoc information about my entire dev environment. How do I manage the multiple handoffs back and forth between AWS CLI and Java?
> There are no good answers.
>     ? Store the results into a file, then use JShell/java(c) to process the output file from Bash/AWS CLI.
>         ? There's multiple handoffs back and forth between AWS CLI and Java. So, every handoff from Java ---> AWS CLI means generating a new file, thus increasing the complexity and cruft. It's unideal.
>     ? Use Java's ProcessBuilder and Process classes.
>         ? This works, but is heavy-handed. Look at the examples in those links. That is multiple lines of code to represent a single bash command. It does appear to be the idiomatic way, though.
>     ? Do all upstream processing with AWS CLI in Bash directly, then do only a single handoff to Java, once I have done all I need to with AWS CLI.
>         ? This is definitely the least painful, but it also means I don't use much Java at all. And any changes in upstream processing must be done in Bash to avoid handoff headaches from AWS CLI ---> Java.
>     ? Download the AWS SDK Jar files and just do it all in Java.
>         ? Ignoring the fact that some things are much harder to do via the AWS Java SDK's, there's actually some functionality that just isn't available via the Java ones. I'd have to recreate it myself, and it would be a significant lift.
> Option 4 is best when I am building an application, but for ad-hoc checks that I want to do on the fly (my most common use-case by far), I have been using Option 3.
> I just wish I could use more Java. It's a FAR BETTERtool than Bash, but I can't justify the level of effort for ad-hoc use cases because of the poor hand off from Java --> Bash. And since AWS CLI is only available via Bash/CMD, I'm stuck with a bunch of not-good choices.
> CLI Scripting in Java is great, but I wanted to highlight this pain point to spread awareness.
> Can you relate?
> 


From asotona at openjdk.org  Tue Apr 15 14:28:03 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 15 Apr 2025 14:28:03 GMT
Subject: RFR: 8350595: 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: <mf5bNccIoYRi_usf9Ob0GGuCrDp5MOAiH1asvA6xiK8=.a516bf54-8421-4ee5-acde-103788037edc@github.com>

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

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

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23899#pullrequestreview-2768583653

From jlahoda at openjdk.org  Wed Apr 16 09:44:01 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Apr 2025 09:44:01 GMT
Subject: Integrated: 8350595: 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: <k7W9FgU6LamjPH-_P7V242RrFkRX6aa7IiP2r1Xe4Dk=.beb25e4c-03b0-4ba7-8dde-0a9ef7877243@github.com>

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

> Adding the `clone()` method to JShell's code completion for arrays.

This pull request has now been integrated.

Changeset: cfbbcd78
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cfbbcd78bc7be2c7740de7c0b49180f56f6ccf49
Stats:     22 lines in 2 files changed: 15 ins; 0 del; 7 mod

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

Reviewed-by: asotona

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

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

From jlahoda at openjdk.org  Wed Apr 16 12:07:45 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 16 Apr 2025 12:07:45 GMT
Subject: RFR: 8352693: Use a simpler console reader instead of JLine for
 System.console() [v4]
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <qjrKrdlFFACyU8RzAnukvjhB_Le4zerLkF7hubd-kZQ=.f2a5a196-4588-4452-8784-023a27922e29@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.

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

  Reflecting review feedback: Adding makefile comment as suggested

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24242/files
  - new: https://git.openjdk.org/jdk/pull/24242/files/daa2cc39..d75641e2

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

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 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 asotona at openjdk.org  Thu Apr 17 07:23:43 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 17 Apr 2025 07:23:43 GMT
Subject: RFR: 8341833: incomplete snippet from loaded files from command
 line is ignored
In-Reply-To: <jTPT3-uBmI6d72QDh34VUmXkwwSLFk5TKJDz9YbFCwM=.aa090ea2-c0a1-4e23-9649-64d3543795a5@github.com>
References: <jTPT3-uBmI6d72QDh34VUmXkwwSLFk5TKJDz9YbFCwM=.aa090ea2-c0a1-4e23-9649-64d3543795a5@github.com>
Message-ID: <le62apsvwWt2-LcvcV2Id17JP5odRs_Vd4y13JmYR14=.993131f1-2197-4bfd-8db0-5cb8e9a7f11a@github.com>

On Fri, 20 Dec 2024 17:32:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> If JShell is run with a parameter that is a file, and the file ends with an incomplete snippet, the incomplete snippet is ignored.
> 
> For example:
> 
> t.jsh:
> class {
> 
> 
>  jshell  /tmp/t.jsh
> |  Welcome to JShell -- Version 21.0.5
> |  For an introduction type: /help intro
> 
> jshell>
> 
> 
> This PR proposes to produce an explicit error in this case:
> 
> $ jshell /tmp/t.jsh 
> Building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Finished building target 'default (exploded-image)' in configuration 'linux-x86_64-server-release'
> Incomplete input: class {
> |  Welcome to JShell -- Version 25-internal
> |  For an introduction type: /help intro
> 
> jshell>

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22850#pullrequestreview-2774829474

From asotona at openjdk.org  Thu Apr 17 07:49:40 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 17 Apr 2025 07:49:40 GMT
Subject: RFR: 8353581: Support for `import module` in JShell's code
 completion
In-Reply-To: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
References: <fjZiBstNWZVORGSdE9HnHyoLD_bLbSZu-b4TkOCjfQc=.a840818f-eafc-4747-a5a8-d7c1226ccf67@github.com>
Message-ID: <evIQcL2pEjk9yNGdjACkC6hP6CUDi_3DH_H-BgKbJ0I=.1c61eee7-155a-4f5d-a65c-b702b130a41d@github.com>

On Fri, 4 Apr 2025 09:08:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adding support for `import module ` to JShell's code completion.

The completion is listed correctly, however it adds(or duplicates) some text to the line.  
For example typing "import module java.<tab>" produces:

jshell> import module java.
java.base             java.compiler         java.datatransfer     java.desktop          java.instrument       java.logging          java.management       java.management.rmi   java.naming           
java.net.http         java.prefs            java.rmi              java.scripting        java.security.jgss    java.security.sasl    java.smartcardio      java.sql              java.sql.rowset       
java.transaction.xa   java.xml              java.xml.crypto       
jshell> import module java.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/24442#issuecomment-2812079481

From archie.cobbs at gmail.com  Thu Apr 17 16:52:21 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 17 Apr 2025 11:52:21 -0500
Subject: PR review requests
Message-ID: <CANSoFxtSq5oWiLybY5uN4xMbcrsgFtFn3cvx7ur-n3jKUfpxcA@mail.gmail.com>

There are a handful of PR's I hope to see included in JDK 25 if possible,
and which have been sitting out there for a while.

If there are any JShell reviewers available, I'd appreciate any reviews of
the following...

   - JDK-8353487: JShell LocalExecutionControl should allow decorating the
   execution task <https://github.com/openjdk/jdk/pull/24398>
   - JDK-8299934: LocalExecutionControl replaces default uncaught exception
   handler <https://github.com/openjdk/jdk/pull/12982>
   - JDK-8350983: JShell LocalExecutionControl only needs stopCheck() on
   backward branches <https://github.com/openjdk/jdk/pull/23850>

The first one has an associated CSR that needs review as well. If I can
help please let me know!

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250417/4c82231f/attachment-0001.htm>