From acobbs at openjdk.org  Mon Jun  3 22:33:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 3 Jun 2024 22:33:35 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <rt4-hFhNIRLJQsUIqBnmUGA38TFNnJsSuFidVrVxATc=.b038c1e5-75ec-4ccb-8dc6-e7fc2cbc784a@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
 <rt4-hFhNIRLJQsUIqBnmUGA38TFNnJsSuFidVrVxATc=.b038c1e5-75ec-4ccb-8dc6-e7fc2cbc784a@github.com>
Message-ID: <vRu42fOsFS1wy7vnLkTWBa_sLXnUyqODFCwjxuIYBWI=.8ea9a8c7-7f7f-4ffc-b743-bc7c5a573b13@github.com>

On Fri, 31 May 2024 06:16:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
>> 
>> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.
>
> Sorry for belated reply. This makes sense to me.

Hi @lahodaj, if you get a chance, please review the CSR [JDK-8333379](https://bugs.openjdk.org/browse/JDK-8333379) or recommend someone else who might be a good reviewer. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19226#issuecomment-2146221755

From asotona at openjdk.org  Tue Jun  4 15:17:48 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 4 Jun 2024 15:17:48 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <uHPyShsCJxwFslId18ezLHJ2KeLQYm_RHSoiMcmtq6w=.78dbbf6f-5427-4ffa-9468-c6027e8fccd6@github.com>

On Thu, 30 May 2024 13:50:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

It looks like a legit performance trick.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19479#pullrequestreview-2096720909

From naoto at openjdk.org  Tue Jun  4 16:33:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Jun 2024 16:33:00 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <ilzj5C5PKI7X0eoPAOR5Ncxmz67dWOsamq4IiA59Qgs=.cd3ec7e3-4db0-4a8c-9952-2bbf2fb6d254@github.com>

On Thu, 30 May 2024 13:50:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

Looks good with a minor nit.

test/jdk/jdk/internal/jline/LazyJdkConsoleProvider.java line 74:

> 72:             ProcessBuilder builder =
> 73:                     ProcessTools.createTestJavaProcessBuilder("--enable-preview",
> 74:                                                               "-verbose:class",

Better to explicitly specify `-Djdk.console=jdk.internal.le`

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

PR Review: https://git.openjdk.org/jdk/pull/19479#pullrequestreview-2096855434
PR Review Comment: https://git.openjdk.org/jdk/pull/19479#discussion_r1626281874

From jlahoda at openjdk.org  Wed Jun  5 05:59:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Jun 2024 05:59:16 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization [v2]
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <Ib8_j-d7hFxapl-DOiA8QRJI0UfA1vofSgrOmJNkJcE=.36c66f32-27a3-475b-8d14-0dc4bddc4f56@github.com>

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

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

  Reflecting review feedback - explicitly selecting the jdk.internal.le provider in the test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19479/files
  - new: https://git.openjdk.org/jdk/pull/19479/files/9886732e..7a0c448f

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

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

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

From jlahoda at openjdk.org  Wed Jun  5 12:36:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Jun 2024 12:36:33 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization [v3]
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <ULRi5T5ytMJO2a3N65np3ePCpnldssTY_wDGxdyoDdg=.327269fd-9961-4920-be99-63b0211fd74e@github.com>

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

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

  Correctly reflecting review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19479/files
  - new: https://git.openjdk.org/jdk/pull/19479/files/7a0c448f..f3259793

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

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

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

From jlahoda at openjdk.org  Wed Jun  5 13:14:24 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Jun 2024 13:14:24 GMT
Subject: RFR: 8332921: Ctrl+C does not call shutdown hooks after JLine upgrade
Message-ID: <MTlsYTg0m8vPTKTuAxM69HZ3Xaa3Hf_dHXlni1WTiWQ=.956ab68d-ae66-49a9-a5e5-ff10039bc95d@github.com>

Some `Terminal` implementations in JLine reset signal handlers to defaults when `nativeSignals` is set to `true`. Traditionally, this setting was `false` by default, but has been changed for JLine 3.6.0 to `true`:
https://github.com/jline/jline3/pull/971

And recently was brought into the JDK via a JLine upgrade. The consequence is that shutdown handlers are no longer called on Ctrl-C, as the signal handler that runs the shutdown handlers is uninstalled is uninstalled.

This patch proposes to adjust the configuration to set `false` to `nativeSignals` explicitly, on both places where we create new terminals.

I was trying to create a test for this fairly hard, but I didn't find a way to write a test that would reliably fail without the patch and reliably pass with it.

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

Commit messages:
 - 8332921: Ctrl+C does not call shutdown hooks after JLine upgrade

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

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

From asotona at openjdk.org  Wed Jun  5 13:42:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Jun 2024 13:42:56 GMT
Subject: RFR: 8332921: Ctrl+C does not call shutdown hooks after JLine
 upgrade
In-Reply-To: <MTlsYTg0m8vPTKTuAxM69HZ3Xaa3Hf_dHXlni1WTiWQ=.956ab68d-ae66-49a9-a5e5-ff10039bc95d@github.com>
References: <MTlsYTg0m8vPTKTuAxM69HZ3Xaa3Hf_dHXlni1WTiWQ=.956ab68d-ae66-49a9-a5e5-ff10039bc95d@github.com>
Message-ID: <i3vvZsl5jM6D9oo69AxYlUZ7qeCi9JcglLjBJ9E3fsw=.560ed2b0-d1b4-47cd-8ca5-e5749b8baf7c@github.com>

On Wed, 5 Jun 2024 13:09:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Some `Terminal` implementations in JLine reset signal handlers to defaults when `nativeSignals` is set to `true`. Traditionally, this setting was `false` by default, but has been changed for JLine 3.6.0 to `true`:
> https://github.com/jline/jline3/pull/971
> 
> And recently was brought into the JDK via a JLine upgrade. The consequence is that shutdown handlers are no longer called on Ctrl-C, as the signal handler that runs the shutdown handlers is uninstalled is uninstalled.
> 
> This patch proposes to adjust the configuration to set `false` to `nativeSignals` explicitly, on both places where we create new terminals.
> 
> I was trying to create a test for this fairly hard, but I didn't find a way to write a test that would reliably fail without the patch and reliably pass with it.

It look good to me and I can confirm it fixes the test case described in the bug.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19559#pullrequestreview-2099242995

From naoto at openjdk.org  Wed Jun  5 17:16:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Jun 2024 17:16:56 GMT
Subject: RFR: 8333086: Using Console.println is unnecessarily slow due to
 JLine initalization [v3]
In-Reply-To: <ULRi5T5ytMJO2a3N65np3ePCpnldssTY_wDGxdyoDdg=.327269fd-9961-4920-be99-63b0211fd74e@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
 <ULRi5T5ytMJO2a3N65np3ePCpnldssTY_wDGxdyoDdg=.327269fd-9961-4920-be99-63b0211fd74e@github.com>
Message-ID: <VXNACBgyDDo6BPzTXiaKOYbwesDagw_o1myy5B0lXU4=.a7435c32-c894-4286-994a-b99c744a54da@github.com>

On Wed, 5 Jun 2024 12:36:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider these two programs:
>> 
>> 
>> public class SystemPrint {
>>     public static void main(String... args) {
>>         System.err.println("Hello!");
>>     }
>> }
>> 
>> and:
>> 
>> public class IOPrint {
>>     public static void main(String... args) {
>>         java.io.IO.println("Hello!");
>>     }
>> }
>> 
>> 
>> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
>> 
>> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
>> 
>> For example, on my computer:
>> 
>> $ time java -classpath /tmp SystemPrint 
>> Hello!
>> 
>> real    0m0,035s
>> user    0m0,019s
>> sys     0m0,019s
>> 
>> $ time java -classpath /tmp --enable-preview IOPrint 
>> Hello!
>> 
>> real    0m0,165s
>> user    0m0,324s
>> sys     0m0,042s
>> 
>> 
>> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
>> 
>> With this patch, I can get timing like this:
>> 
>> $ time java --enable-preview -classpath /tmp/ IOPrint 
>> Hello!
>> 
>> real    0m0,051s
>> user    0m0,038s
>> sys     0m0,020s
>> 
>> 
>> which seems much more acceptable.
>> 
>> There is also #19467, which may reduce the time further.
>> 
>> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correctly reflecting review feedback

LGTM. Thanks for the changes.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19479#pullrequestreview-2099801902

From jlahoda at openjdk.org  Wed Jun  5 17:23:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Jun 2024 17:23:02 GMT
Subject: Integrated: 8333086: Using Console.println is unnecessarily slow due
 to JLine initalization
In-Reply-To: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
References: <H9mNqL67B1jUNevUVidObx5gBGJEKYqolrR_OABapDQ=.be099164-4d6c-4d1d-ab6b-20d7b41fab76@github.com>
Message-ID: <fydIIdPjQWj9UO6r7Gg077GfmupsjYAp_8YfwuqTjLI=.f6e5a5b2-3f60-4121-93de-f6b843b83124@github.com>

On Thu, 30 May 2024 13:50:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider these two programs:
> 
> 
> public class SystemPrint {
>     public static void main(String... args) {
>         System.err.println("Hello!");
>     }
> }
> 
> and:
> 
> public class IOPrint {
>     public static void main(String... args) {
>         java.io.IO.println("Hello!");
>     }
> }
> 
> 
> They do the same conceptual thing - write a text to the output. But, `IO.println` delegates to `Console.println`, which then delegates to a `Console` backend, and the default backend is currently based on JLine.
> 
> The issues is that JLine takes a quite a long time to initialize, and in a program like this, JLine is not really needed - it is used to provide better editing experience when reading input, but there's no reading in these programs.
> 
> For example, on my computer:
> 
> $ time java -classpath /tmp SystemPrint 
> Hello!
> 
> real    0m0,035s
> user    0m0,019s
> sys     0m0,019s
> 
> $ time java -classpath /tmp --enable-preview IOPrint 
> Hello!
> 
> real    0m0,165s
> user    0m0,324s
> sys     0m0,042s
> 
> 
> The proposal herein is to delegate to the simpler `Console` backend from `java.base` as long as the user only uses methods that print to output, and switch to the JLine delegate when other methods (typically input) is used. Note that while technically `writer()` is a method doing output, it will force JLine initialization to avoid possible problems if the client caches the writer and uses it after switching the delegates.
> 
> With this patch, I can get timing like this:
> 
> $ time java --enable-preview -classpath /tmp/ IOPrint 
> Hello!
> 
> real    0m0,051s
> user    0m0,038s
> sys     0m0,020s
> 
> 
> which seems much more acceptable.
> 
> There is also #19467, which may reduce the time further.
> 
> A future work might focus on making JLine initialize faster, but avoiding JLine initialization in case where we don't need it seems like a good step to me in any case.

This pull request has now been integrated.

Changeset: f7dbb98f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7dbb98fe69eb98f8544577d81550b4fd817864b
Stats:     226 lines in 2 files changed: 213 ins; 1 del; 12 mod

8333086: Using Console.println is unnecessarily slow due to JLine initalization

Reviewed-by: asotona, naoto

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

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

From jlahoda at openjdk.org  Wed Jun  5 17:29:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Jun 2024 17:29:13 GMT
Subject: RFR: 8332921: Ctrl+C does not call shutdown hooks after JLine
 upgrade [v2]
In-Reply-To: <MTlsYTg0m8vPTKTuAxM69HZ3Xaa3Hf_dHXlni1WTiWQ=.956ab68d-ae66-49a9-a5e5-ff10039bc95d@github.com>
References: <MTlsYTg0m8vPTKTuAxM69HZ3Xaa3Hf_dHXlni1WTiWQ=.956ab68d-ae66-49a9-a5e5-ff10039bc95d@github.com>
Message-ID: <iEPiTWTXUq9lIcmOiLCGOoSkkrxVhDzCup2DBJ3Cpv4=.9109593b-f02c-4e0d-b4bb-f052aec62b26@github.com>

> Some `Terminal` implementations in JLine reset signal handlers to defaults when `nativeSignals` is set to `true`. Traditionally, this setting was `false` by default, but has been changed for JLine 3.6.0 to `true`:
> https://github.com/jline/jline3/pull/971
> 
> And recently was brought into the JDK via a JLine upgrade. The consequence is that shutdown handlers are no longer called on Ctrl-C, as the signal handler that runs the shutdown handlers is uninstalled is uninstalled.
> 
> This patch proposes to adjust the configuration to set `false` to `nativeSignals` explicitly, on both places where we create new terminals.
> 
> I was trying to create a test for this fairly hard, but I didn't find a way to write a test that would reliably fail without the patch and reliably pass with it.

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

 - Merge branch 'master' into JDK-8332921
 - 8332921: Ctrl+C does not call shutdown hooks after JLine upgrade

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

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

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

From vromero at openjdk.org  Wed Jun  5 18:14:59 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 5 Jun 2024 18:14:59 GMT
Subject: RFR: 8332921: Ctrl+C does not call shutdown hooks after JLine
 upgrade [v2]
In-Reply-To: <iEPiTWTXUq9lIcmOiLCGOoSkkrxVhDzCup2DBJ3Cpv4=.9109593b-f02c-4e0d-b4bb-f052aec62b26@github.com>
References: <MTlsYTg0m8vPTKTuAxM69HZ3Xaa3Hf_dHXlni1WTiWQ=.956ab68d-ae66-49a9-a5e5-ff10039bc95d@github.com>
 <iEPiTWTXUq9lIcmOiLCGOoSkkrxVhDzCup2DBJ3Cpv4=.9109593b-f02c-4e0d-b4bb-f052aec62b26@github.com>
Message-ID: <G7m6QLM0ubQU9xLxEAhjk7rBfx45VqDx3i21-jN5i24=.eec2cf1f-32c9-4f92-8a9f-f4501aaa8c58@github.com>

On Wed, 5 Jun 2024 17:29:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Some `Terminal` implementations in JLine reset signal handlers to defaults when `nativeSignals` is set to `true`. Traditionally, this setting was `false` by default, but has been changed for JLine 3.6.0 to `true`:
>> https://github.com/jline/jline3/pull/971
>> 
>> And recently was brought into the JDK via a JLine upgrade. The consequence is that shutdown handlers are no longer called on Ctrl-C, as the signal handler that runs the shutdown handlers is uninstalled is uninstalled.
>> 
>> This patch proposes to adjust the configuration to set `false` to `nativeSignals` explicitly, on both places where we create new terminals.
>> 
>> I was trying to create a test for this fairly hard, but I didn't find a way to write a test that would reliably fail without the patch and reliably pass with it.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8332921
>  - 8332921: Ctrl+C does not call shutdown hooks after JLine upgrade

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19559#pullrequestreview-2099920001

From jlahoda at openjdk.org  Thu Jun  6 04:46:48 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 6 Jun 2024 04:46:48 GMT
Subject: Integrated: 8332921: Ctrl+C does not call shutdown hooks after JLine
 upgrade
In-Reply-To: <MTlsYTg0m8vPTKTuAxM69HZ3Xaa3Hf_dHXlni1WTiWQ=.956ab68d-ae66-49a9-a5e5-ff10039bc95d@github.com>
References: <MTlsYTg0m8vPTKTuAxM69HZ3Xaa3Hf_dHXlni1WTiWQ=.956ab68d-ae66-49a9-a5e5-ff10039bc95d@github.com>
Message-ID: <BlyDPN4PzH4na4feKeHRjeA_6pmS4zdGnPhSH3Ii2no=.da463239-811f-40a2-a282-d869e0cca3af@github.com>

On Wed, 5 Jun 2024 13:09:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Some `Terminal` implementations in JLine reset signal handlers to defaults when `nativeSignals` is set to `true`. Traditionally, this setting was `false` by default, but has been changed for JLine 3.6.0 to `true`:
> https://github.com/jline/jline3/pull/971
> 
> And recently was brought into the JDK via a JLine upgrade. The consequence is that shutdown handlers are no longer called on Ctrl-C, as the signal handler that runs the shutdown handlers is uninstalled is uninstalled.
> 
> This patch proposes to adjust the configuration to set `false` to `nativeSignals` explicitly, on both places where we create new terminals.
> 
> I was trying to create a test for this fairly hard, but I didn't find a way to write a test that would reliably fail without the patch and reliably pass with it.

This pull request has now been integrated.

Changeset: b3f540d3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3f540d354c4a4e2f2199019a2b880a373699560
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8332921: Ctrl+C does not call shutdown hooks after JLine upgrade

Reviewed-by: asotona, vromero

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

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

From hgreule at openjdk.org  Thu Jun  6 16:56:53 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 6 Jun 2024 16:56:53 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v4]
In-Reply-To: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
Message-ID: <vUHlyUETNoun_Tr-aBZurgBZ8AMN9u8gxZM63JNJpEQ=.3569ac3d-b9b2-4473-a9c7-081ab27b1c8e@github.com>

> Pasting  e.g.
> 
> I m(I i, int x) {
>    return switch (x) {
>         default -> i;
>    };
> }
> 
> in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch.
> 
> Javac will not crash but swallow the exception, and create a file containing the command line options.
> 
> I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally.

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

 - Merge branch 'master' into fix/switch-yield-unknown-type-crash
   
   # Conflicts:
   #	test/langtools/tools/javac/recovery/AttrRecovery.java
 - add testcase
 - Don't bail out early on erroneous type, adjust tests
 - Merge branch 'master' into fix/switch-yield-unknown-type-crash
 - Merge branch 'master' into fix/switch-yield-unknown-type-crash
 - Merge branch 'refs/heads/master' into fix/switch-yield-unknown-type-crash
 - add bug id
 - Fix jshell crash on unknown type in switch yield

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

Changes: https://git.openjdk.org/jdk/pull/18383/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18383&range=03
  Stats: 54 lines in 6 files changed: 47 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18383/head:pull/18383

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

From nbenalla at openjdk.org  Fri Jun  7 09:16:13 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 7 Jun 2024 09:16:13 GMT
Subject: RFR: 8332014: since-checker - Fix @ since tags in jdk.jshell [v2]
In-Reply-To: <BIkUHfaQncAbpj_gqToVnwqZfwcoPdkXM2VdYtEBSzU=.43cd78a2-79fd-4d35-b3e9-6e1693c30bc7@github.com>
References: <EEVWpO4_ntUkpN3GbUMBSKPJ5q9KPCEQmFazVlNecTc=.97af6015-1c8a-4a9f-b869-a99adfaa979a@github.com>
 <BIkUHfaQncAbpj_gqToVnwqZfwcoPdkXM2VdYtEBSzU=.43cd78a2-79fd-4d35-b3e9-6e1693c30bc7@github.com>
Message-ID: <eetfzYpmt31S3ImzXMx4xGsZPbWufGchhzI5G_IdlPw=.f4c50fd9-e4fa-4abf-86c5-a20a04ad7151@github.com>

On Fri, 10 May 2024 02:25:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

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

I wish to keep this open.

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

PR Comment: https://git.openjdk.org/jdk/pull/19166#issuecomment-2154429211

From dholmes at openjdk.org  Mon Jun 10 02:38:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 02:38:25 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
Message-ID: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>

Sets the version to 24/24-ea and the copyright year to 2025.

Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.

This initial generation also picks up the unpublished changes from: 

- JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
- JDK-8284500: Typo in Supported Named Extensions - BasicContraints
- JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class

Thanks

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

Commit messages:
 - 8330205: Initial troff manpage generation for JDK 24

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

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

From alanb at openjdk.org  Mon Jun 10 07:18:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Jun 2024 07:18:11 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class
> 
> Thanks

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2106832118

From dholmes at openjdk.org  Mon Jun 10 08:04:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Jun 2024 08:04:12 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
 <3hAM5el3W8wXMgyjuCGXpmRjCxld2dvHMiUbvarBPhU=.62cd1645-6bf1-4da4-b70e-70c12e6377c8@github.com>
Message-ID: <G-MYWkkw506r9DLMCcme6orMWiD3hu1Wn6nRJuSIG_c=.94373b8a-b647-4e59-9a3e-053c012032aa@github.com>

On Mon, 10 Jun 2024 07:15:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sets the version to 24/24-ea and the copyright year to 2025.
>> 
>> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
>> 
>> This initial generation also picks up the unpublished changes from: 
>> 
>> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
>> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
>> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
>> 
>> Thanks
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2157606095

From iris at openjdk.org  Mon Jun 10 17:30:15 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Jun 2024 17:30:15 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19617#pullrequestreview-2108383696

From dnguyen at openjdk.org  Mon Jun 10 20:05:33 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
Message-ID: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.

The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.

Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
https://cr.openjdk.org/~dnguyen/output2/

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

Commit messages:
 - Review comment edits
 - Initial localization changes

Changes: https://git.openjdk.org/jdk/pull/19609/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333827
  Stats: 239 lines in 39 files changed: 133 ins; 57 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/19609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19609/head:pull/19609

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

From achung at openjdk.org  Mon Jun 10 20:05:33 2024
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <b6aneCOmBcnk_v0W_sl89B94wwIeT12Zf2GwtSaG99A=.5d32dade-5b56-4179-9bbe-f07eb0352cfb@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Just a question about the reverted translations, otherwise LGTM

> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.

Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated?

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

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2105526180
PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2155723513

From jlu at openjdk.org  Mon Jun 10 20:05:33 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Cannot speak to the translations themselves, but in general the changes LGTM pending the comments.

src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1:

> 1: #

It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions.

src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66:

> 64: label.size=??(&Z):
> 65: label.source=??(&C):
> 66: label.outputbins=????(&P)?

Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278:

> 276:         UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}".
> 277:         UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden.
> 278:         ENTITYFailedInitializeGrammar =  ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t

It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool.

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 285:

> 283: VIRTUAL_MACHINE=Virtuelle Maschine
> 284: VM_ARGUMENTS=VM-Argumente
> 285: VMINTERNAL_FRAME_ACCESSIBLE_DESCRIPTION=Innerer Frame f?r das Monitoring einer Java Virtual Machine

This one-off change is consistent with the change in _src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java_.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:

> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
> 182: 
> 183: help.usage = Verwendung:   jshell <option>... <load-file>...\nM?gliche Optionen:\n    --class-path <path>   Gibt an, wo die Benutzerklassendateien gespeichert sind\n    --module-path <path>  Gibt an, wo die Anwendungsmodule gespeichert sind\n    --add-modules <module>(,<module>)*\n                          Gibt aufzul?sende Module oder alle Module im\n                            Modulpfad an, wenn <module> ALL-MODULE-PATHs lautet\n    --enable-native-access\n                          Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n    --enable-preview      Code kann Vorschaufeatures in diesem Release nutzen\n    --startup <Datei>      Ersetzung der Startdefinitionen mit einer Ausf?hrung\n    --no-startup          Startdefinitionen werden nicht ausgef?hrt\n    --feedback <Modus>     Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n                            vordefiniert (Silent, Concise, Normal oder Verbose) oder\n                            v
 orab benutzerdefiniert sein\n    -q                    Stilles Feedback. Identisch mit: --feedback concise\n    -s                    ?u?erst stilles Feedback. Identisch mit: --feedback silent\n    -v                    Verbose-Feedback. Identisch mit: --feedback verbose\n    -J<flag>              ?bergibt <flag> an das Laufzeitsystem, hat aber keine Auswirkungen\n                            auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n                            die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n                            -R<flag>. Verwenden Sie alternativ dazu -J<flag> mit\n                            --execution local.\n    -R<flag>              ?bergibt <flag> nur dann an das Laufzeitsystem, wenn\n                            Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n                            bedeutet, dass die Ausf?hrung des Snippets\n                            System.getProperty("foo") "bar" zur?ckgi
 bt.\n    -C<flag>              ?bergibt <flag> an den Java-Compiler in JShell.\n                            Beispiel: -C-Xlint aktiviert alle empfohlenen\n                            LINT-Warnungen, und -C--release=<N> kompiliert f?r\n                            Java SE N, wie wenn --release N angegeben wird.\n                            Verwenden Sie ein -C pro Compiler-Kennzeichen oder Kennzeichenargument\n    --version             Gibt Versionsinformationen aus und beendet den Vorgang\n    --show-version        Gibt Versionsinformationen aus und setzt den Vorgang fort\n    --help, -?, -h        Gibt diese Zusammenfassung der Standardoptionen aus und beendet den Vorgang\n    --help-extra, -X      Gibt Hilfetext zu Nicht-Standardoptionen aus und beendet den Vorgang\n\nEin Dateiargument kann ein Dateiname oder einer der vordefinierten Dateinamen sein: DEFAULT,\nPRINTING, TOOLING oder JAVASE.\nEine Ladedatei kann auch "-" zur Angabe einer Standardeingabe ohne interaktiven I/O sein.
 \n\nWeitere Informationen zu den Auswertungskontextoptionen (--class-path,\n--module-path und --add-modules) finden Sie unter:\n\t/help context\n\nEin Pfad listet die zu durchsuchenden Verzeichnisse und Archive auf. Verwenden Sie unter Windows ein\nSemikolon (;), um Elemente im Pfad zu trennen. Verwenden Sie auf anderen Plattformen einen\nDoppelpunkt (:), um Elemente zu trennen.\n

> Any particular reason you know that the tool had the definitions adjusted? I see some of the changes look like like command line options not being translated, but it's a bit hard to tell. Do you know if the reverted words should be translated (and possibly will be re-translated in future drops?) or should they be left untranslated?

@alisenchung While these command line options are untranslated, which initially may seem confusing, it appears to be the translation tool standardizing the definitions with the Japanese and Chinese localized definitions. We should leave them untranslated.

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

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2106349441
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632407907
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632376640
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632375726
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632377328
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632373349

From dnguyen at openjdk.org  Mon Jun 10 20:05:33 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:05:33 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
Message-ID: <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>

On Sun, 9 Jun 2024 22:49:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using John Gibbon's diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 1:
> 
>> 1: #
> 
> It looks like these .properties files need to have their copyright years bumped. I believe since the original was not bumped, the translation tool did not reflect the correct year in the localized versions.

Right, the source file has the copyright year of 2019, and these translated files reflect that, so I believe this is OK.

> src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 66:
> 
>> 64: label.size=??(&Z):
>> 65: label.source=??(&C):
>> 66: label.outputbins=????(&P)?
> 
> Looks like the translation tool changed this from a colon (U+003A) to a full width colon (U+FF1A). There are l10n rules when it comes to punctuation, I am not sure if this is a result of that. It looks like the surrounding key/values are simply using (U+003A) colons. If we decide to revert this colon change, we need to also probably file a bug against the translation tool.

Right, I agree. I'm OK with either decision too, but I'm leaning towards reverting this to standardize the colons since the rest are (U+003A). Maybe a reviewer from desktop can chime in once this PR is undrafted.

> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278:
> 
>> 276:         UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}".
>> 277:         UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden.
>> 278:         ENTITYFailedInitializeGrammar =  ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t
> 
> It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool.

Yeah, I believe you're right. Noted as something else to file against the translation tool.

> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:
> 
>> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
>> 182: 
>> 183: help.usage = Verwendung:   jshell <option>... <load-file>...\nM?gliche Optionen:\n    --class-path <path>   Gibt an, wo die Benutzerklassendateien gespeichert sind\n    --module-path <path>  Gibt an, wo die Anwendungsmodule gespeichert sind\n    --add-modules <module>(,<module>)*\n                          Gibt aufzul?sende Module oder alle Module im\n                            Modulpfad an, wenn <module> ALL-MODULE-PATHs lautet\n    --enable-native-access\n                          Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n    --enable-preview      Code kann Vorschaufeatures in diesem Release nutzen\n    --startup <Datei>      Ersetzung der Startdefinitionen mit einer Ausf?hrung\n    --no-startup          Startdefinitionen werden nicht ausgef?hrt\n    --feedback <Modus>     Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n                            vordefiniert (Silent, Concise, Normal oder Verbose) oder\n                            
 vorab benutzerdefiniert sein\n    -q                    Stilles Feedback. Identisch mit: --feedback concise\n    -s                    ?u?erst stilles Feedback. Identisch mit: --feedback silent\n    -v                    Verbose-Feedback. Identisch mit: --feedback verbose\n    -J<flag>              ?bergibt <flag> an das Laufzeitsystem, hat aber keine Auswirkungen\n                            auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n                            die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n                            -R<flag>. Verwenden Sie alternativ dazu -J<flag> mit\n                            --execution local.\n    -R<flag>              ?bergibt <flag> nur dann an das Laufzeitsystem, wenn\n                            Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n                            bedeutet, dass die Ausf?hrung des Snippets\n                            System.getProperty("foo") "bar" zur?ckg
 ibt.\n    -C<flag>              ?bergibt <flag> an den Java-Compiler in JShell.\n                            Beispiel: -C-Xlint aktiviert alle empfohlenen\n                           ...

This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633762275
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632401147
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633748812
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1632401256

From jjg at openjdk.org  Mon Jun 10 20:15:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 20:15:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
Message-ID: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>

On Sun, 9 Jun 2024 22:07:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties line 183:
>> 
>>> 181: jshell.fix.wrong.shortcut =Unerwartetes Zeichen nach Umschalt+Tab.\nVerwenden Sie "I" f?r automatischen Import, "V" zur Variablenerstellung oder "M" zur Methodenerstellung.\nWeitere Informationen finden Sie unter:\n/help shortcuts
>>> 182: 
>>> 183: help.usage = Verwendung:   jshell <option>... <load-file>...\nM?gliche Optionen:\n    --class-path <path>   Gibt an, wo die Benutzerklassendateien gespeichert sind\n    --module-path <path>  Gibt an, wo die Anwendungsmodule gespeichert sind\n    --add-modules <module>(,<module>)*\n                          Gibt aufzul?sende Module oder alle Module im\n                            Modulpfad an, wenn <module> ALL-MODULE-PATHs lautet\n    --enable-native-access\n                          Erm?glicht Ausf?hrung eingeschr?nkter nativer Methoden durch Code\n    --enable-preview      Code kann Vorschaufeatures in diesem Release nutzen\n    --startup <Datei>      Ersetzung der Startdefinitionen mit einer Ausf?hrung\n    --no-startup          Startdefinitionen werden nicht ausgef?hrt\n    --feedback <Modus>     Gibt den anf?nglichen Feedbackmodus an. Der Modus kann\n                            vordefiniert (Silent, Concise, Normal oder Verbose) oder\n                           
  vorab benutzerdefiniert sein\n    -q                    Stilles Feedback. Identisch mit: --feedback concise\n    -s                    ?u?erst stilles Feedback. Identisch mit: --feedback silent\n    -v                    Verbose-Feedback. Identisch mit: --feedback verbose\n    -J<flag>              ?bergibt <flag> an das Laufzeitsystem, hat aber keine Auswirkungen\n                            auf die Ausf?hrung von Code-Snippets. Um Kennzeichen anzugeben,\n                            die die Ausf?hrung von Code-Snippets beeinflussen, verwenden Sie\n                            -R<flag>. Verwenden Sie alternativ dazu -J<flag> mit\n                            --execution local.\n    -R<flag>              ?bergibt <flag> nur dann an das Laufzeitsystem, wenn\n                            Code-Snippets ausgef?hrt werden. Beispiel: -R-Dfoo=bar\n                            bedeutet, dass die Ausf?hrung des Snippets\n                            System.getProperty("foo") "bar" zur?ck
 gibt.\n    -C<flag>              ?bergibt <flag> an den Java-Compiler in JShell.\n                            Beispiel: -C-Xlint aktiviert alle empfohlenen\n                    ...
>
> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.

While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, `<args>`, `<class-path>`.

This change seems to be going backwards.

Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633774912

From prr at openjdk.org  Mon Jun 10 20:23:22 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 10 Jun 2024 20:23:22 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 66:

> 64: label.size=G&r??e:
> 65: label.source=&Quelle:
> 66: label.outputbins=A&usgabef?cher:

How confident are we in this ?
google translate says that the old text referred to 'compartments' and the new one to 'areas' and I wonder why that is better ?

https://translate.google.com/?sl=auto&tl=en&text=Ausgabebereiche%0AAusgebefacher&op=translate

src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 32:

> 30: border.jobattributes=????
> 31: border.media=??
> 32: border.output=??

What triggered this ? Just someone noticing it and deciding there's a better translation ?
What does it say ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633781646
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633782742

From jjg at openjdk.org  Mon Jun 10 20:23:23 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 20:23:23 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <SjpwOVwkqCFBlC_Vj1rv4JwgHdgqnpiz8xrDTE98eOc=.c90d5753-0206-48e9-bfb4-8e6bc67c616a@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 409:

> 407: compiler.err.unconditional.pattern.and.default=Switch umfasst sowohl ein nicht bedingtes Muster als auch ein Standardlabel
> 408: 
> 409: compiler.err.unconditional.pattern.and.both.boolean.values=Switch umfasst sowohl boolesche Werte als auch ein nicht bedingtes Muster

Here and elsewhere in this file and other translations, I'm surprised `switch` is not being translated, and is being capitalized. In the English form, it is not being used as a keyword, although could maybe be seen as a short form of `switch' statement, in which case `switch` should be treated as a keyword and not translated or capitalized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633782242

From dnguyen at openjdk.org  Mon Jun 10 20:37:13 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:37:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <SjpwOVwkqCFBlC_Vj1rv4JwgHdgqnpiz8xrDTE98eOc=.c90d5753-0206-48e9-bfb4-8e6bc67c616a@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <SjpwOVwkqCFBlC_Vj1rv4JwgHdgqnpiz8xrDTE98eOc=.c90d5753-0206-48e9-bfb4-8e6bc67c616a@github.com>
Message-ID: <2-SMv3j3Eqrv7LVV6CbkZVEb3KFcahQR1_8AiJErDAQ=.07538bd6-9b25-45ed-b47f-8e9102ea8af9@github.com>

On Mon, 10 Jun 2024 20:20:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 409:
> 
>> 407: compiler.err.unconditional.pattern.and.default=Switch umfasst sowohl ein nicht bedingtes Muster als auch ein Standardlabel
>> 408: 
>> 409: compiler.err.unconditional.pattern.and.both.boolean.values=Switch umfasst sowohl boolesche Werte als auch ein nicht bedingtes Muster
> 
> Here and elsewhere in this file and other translations, I'm surprised `switch` is not being translated, and is being capitalized. In the English form, it is not being used as a keyword, although could maybe be seen as a short form of `switch' statement, in which case `switch` should be treated as a keyword and not translated or capitalized.

Good catch. Seems to be across all files and I'm assuming it's for the reason you suggested. I'll bring this up to the go team. I have no way to fix this since I can't rely on google translate. This can be caught in a future update if the go team can successfully differentiate the difference between the word `switch` and a `switch keyword`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633796771

From dnguyen at openjdk.org  Mon Jun 10 20:37:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:37:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
Message-ID: <P4mDp3QdSzjC6Fdj2ZmhOdNl5GcRrEb6PexlIZYYHpI=.9b384ebb-9dee-4b33-8fc2-370818ac80a3@github.com>

On Mon, 10 Jun 2024 20:12:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.
>
> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, `<args>`, `<class-path>`.
> 
> This change seems to be going backwards.
> 
> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.

The go translation team dictates which of these segments within a file actually get updated. I can manually revert the segments if preferred, but these changes will continue appearing for future drops with the current system. 

I can potentially try to communicate to the other team to differentiate between keywords & option names versus some of these other words, but let me know how you'd like me to proceed with this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633794362

From dnguyen at openjdk.org  Mon Jun 10 20:40:15 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 20:40:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
Message-ID: <0xmUIRy1V_ts7yyfm1kMaQfbzU5YoJSWAzD3QDNLY7U=.8e0e163e-d0c6-4f22-a92d-79de8c58e8f6@github.com>

On Mon, 10 Jun 2024 20:20:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 32:
> 
>> 30: border.jobattributes=????
>> 31: border.media=??
>> 32: border.output=??
> 
> What triggered this ? Just someone noticing it and deciding there's a better translation ?
> What does it say ?

In the past, it was brought up in review that some of the words were translated to localized words that didn't exactly mean what the original English word meant. I believe Weijun Wang caught some of these in Chinese files in the past.  I'm assuming these are cases where the go team is improving the translation, but I also can't exactly tell. We do suggest changes to the go team, so maybe this is evidence of them improving their tool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633801033

From naoto at openjdk.org  Mon Jun 10 20:49:13 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Jun 2024 20:49:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Did not look at each for translation accuracy (did some for Japanese), but looks good overall.
It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2108722631

From dnguyen at openjdk.org  Mon Jun 10 21:45:13 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:45:13 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
Message-ID: <ib1NQFG8TW7Wr6ZMzxxxF5JreiZiVPHoyTHn--6ad2k=.f01f7a8c-49cc-42fc-84f3-16a6afc5b8fc@github.com>

On Mon, 10 Jun 2024 20:46:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Did not look at each for translation accuracy (did some for Japanese), but looks good overall. It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!

Justin's tool is responsible for this. Made the process quicker/simpler as well once everything was setup properly and working.

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

PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2159331304

From dnguyen at openjdk.org  Mon Jun 10 21:45:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:45:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
Message-ID: <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>

On Mon, 10 Jun 2024 20:12:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is what I've determined as well. I planned to leave these untranslated to reduce noise between drops as well.
>
> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, `<args>`, `<class-path>`.
> 
> This change seems to be going backwards.
> 
> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.

@jonathan-gibbons I just realized that this change to the German file matches the file with the Japanese and Chinese localized files. By that I mean the "backwards" translations are also present for the Japanese and Chinese files.

However, the previous versions of the Japanese and Chinese files don't have these bits translated. So in summary, I can revert the German file back to German but the Japanese and Chinese files will still be English for these parts because I wouldn't know what to revert them to in their local language.

As a result, I actually think it might be better to change this German file as shown in the current version of the PR just to remain consistent with the other localized versions of this file. We can still bring this up to the go team as an issue, but I think this is the best solution now for this drop at least.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633859027

From joehw at openjdk.org  Mon Jun 10 21:54:14 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 10 Jun 2024 21:54:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <ADcUl2k8pnbEDcAvLsEOBA05LjviX8HmX3OAlGEK5Mw=.05eee615-de93-4792-a8d8-5c2ea8a0dabe@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

One minor comment, otherwise the java.xml changes look good.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 331:

> 329: 
> 330: # Implementation Property DTD
> 331:         JDK_DTD_DENY = JAXP00010008: DOCTYPE ist nicht zul?ssig, wenn die DTD-Eigenschaft auf "Ablehnen" gesetzt wurde. Weitere Informationen: Eigenschaft jdk.xml.dtd.support in java.xml/module-summary.

either drop the double quote in "Ablehnen" or use the literal without translation, that is, "deny".

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2108813421
PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633870136

From dnguyen at openjdk.org  Mon Jun 10 21:58:29 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 21:58:29 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Remove double quotes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19609/files
  - new: https://git.openjdk.org/jdk/pull/19609/files/9125337b..32d69e89

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

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

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

From cjplummer at openjdk.org  Mon Jun 10 22:27:15 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 10 Jun 2024 22:27:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
Message-ID: <ivxoCg1QhjwpzbGR6T6rHreTkqv-NVFo7jZYwNL0LiM=.c10bee70-9ca8-4db5-89b1-ee7682729e3d@github.com>

On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double quotes

src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 325:

> 323:         {"Unexpected event type", "Unerwarteter Ereignistyp: {0}"},
> 324:         {"unknown", "unbekannt"},
> 325:         {"Unmonitoring", "Monitoring von {0} aufheben"},

The English entry is:

        {"Unmonitoring", "Unmonitoring {0} "},

But the German entry now says "Monitoring". I'm  sure what the original "\u00DCberwachung" translates to, other than berwachung is monitoring. Now this resource is partly in English, and is the incorrect English.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633902362

From dnguyen at openjdk.org  Mon Jun 10 22:51:14 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 10 Jun 2024 22:51:14 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <ivxoCg1QhjwpzbGR6T6rHreTkqv-NVFo7jZYwNL0LiM=.c10bee70-9ca8-4db5-89b1-ee7682729e3d@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
 <ivxoCg1QhjwpzbGR6T6rHreTkqv-NVFo7jZYwNL0LiM=.c10bee70-9ca8-4db5-89b1-ee7682729e3d@github.com>
Message-ID: <iJZMTs0UUdFqw07uiMXQrkv3QBeyv70VQyyVZtFy5k4=.22762511-49c4-4ad6-a198-38d2be8ac4f6@github.com>

On Mon, 10 Jun 2024 22:19:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove double quotes
>
> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 325:
> 
>> 323:         {"Unexpected event type", "Unerwarteter Ereignistyp: {0}"},
>> 324:         {"unknown", "unbekannt"},
>> 325:         {"Unmonitoring", "Monitoring von {0} aufheben"},
> 
> The English entry is:
> 
>         {"Unmonitoring", "Unmonitoring {0} "},
> 
> But the German entry now says "Monitoring". I'm  sure what the original "\u00DCberwachung" translates to, other than berwachung is monitoring. Now this resource is partly in English, and is the incorrect English.

I don't know German, but when plugging `"Monitoring von {0} aufheben"` into google translate, I get `Unmonitoring` as well. Maybe `Monitoring` is a word that could also be used in German? No clue. The translation tool decided to make this change.

@sormuras do you have any input on this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633925334

From jjg at openjdk.org  Mon Jun 10 23:13:15 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 10 Jun 2024 23:13:15 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
 <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
Message-ID: <Ss1KZ4NwolVYPiXv46jXJ05_pDMCkOY4GHYlq5stnCc=.135e6f50-206b-4f75-acf4-4574eaf84951@github.com>

On Mon, 10 Jun 2024 21:38:18 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> While we do not translate Java keywords (when used as such, e.g. "`class` not allowed here"), and option names (e.g. `--class-path`) we have typically translated other text that is not mandated by the language or tools, (e.g. `the name of this class`, `<args>`, `<class-path>`.
>> 
>> This change seems to be going backwards.
>> 
>> Whatever the policy we use for translating (or not translating) parts of a message, we should be consistent across all tools and documents.
>
> @jonathan-gibbons I just realized that this change to the German file matches the file with the Japanese and Chinese localized files. By that I mean the "backwards" translations are also present for the Japanese and Chinese files.
> 
> However, the previous versions of the Japanese and Chinese files don't have these bits translated. So in summary, I can revert the German file back to German but the Japanese and Chinese files will still be English for these parts because I wouldn't know what to revert them to in their local language.
> 
> As a result, I actually think it might be better to change this German file as shown in the current version of the PR just to remain consistent with the other localized versions of this file. We can still bring this up to the go team as an issue, but I think this is the best solution now for this drop at least.

No one else except people reading this PR will spot inconsistencies between translations in different languages. So inconsistencies across languages will not be obvious to end users.

But anyone (end-user) using the tool in any one of these languages is likely to spot inconsistencies in the translations for that one language.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1633937355

From dholmes at openjdk.org  Tue Jun 11 00:50:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 00:50:28 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v2]
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <aepA-ImIyckFwPaf4cS2pizlON3SYyrfc5BK9Y1SJwU=.50de780d-25c0-4da3-9066-52b1a472b8de@github.com>

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge
 - 8330205: Initial troff manpage generation for JDK 24

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

Changes: https://git.openjdk.org/jdk/pull/19617/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=01
  Stats: 53 lines in 28 files changed: 12 ins; 3 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/19617.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617

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

From dholmes at openjdk.org  Tue Jun 11 01:02:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:02:39 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <fxPYBQ2lvXomy6ZaWwe2l7ucWeyV5Yd9dl7b7lZl5ho=.e8c4eae1-cf24-42e2-a86a-f5e3e0f6163c@github.com>

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Regenerated after merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19617/files
  - new: https://git.openjdk.org/jdk/pull/19617/files/8472c47d..e7563087

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

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

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

From dholmes at openjdk.org  Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: RFR: 8330205: Initial troff manpage generation for JDK 24 [v3]
In-Reply-To: <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
 <uNkk5qQaPdNEfH5YxUXvQL8CFKT63f4P-PKcE3vKcMw=.6270cb01-eb8e-4f51-986c-5e93ec02cdcf@github.com>
Message-ID: <7aiYPjUq_qkJuy1jRAFfZTpNoCwaw9scrgKJkkbp6UA=.dcdfae3e-05c5-45af-81b4-8a434b2774ba@github.com>

On Mon, 10 Jun 2024 17:27:18 GMT, Iris Clark <iris at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Regenerated after merge
>
> Marked as reviewed by iris (Reviewer).

Thanks for the review @irisclark .

I've merged in the latest updates that also brought in part of the missing changes. If anything goes wrong I have another PR in preparation that also updates java.1

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

PR Comment: https://git.openjdk.org/jdk/pull/19617#issuecomment-2159577044

From dholmes at openjdk.org  Tue Jun 11 01:08:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 01:08:22 GMT
Subject: Integrated: 8330205: Initial troff manpage generation for JDK 24
In-Reply-To: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
References: <DxoS-iKUeC49_UYnIweL_1dLvlnbZlWLwt8PdjV9YFU=.39b7a1f3-b16c-439a-901d-cc8ca9d87882@github.com>
Message-ID: <rZfMnH59MoMxA4EjbTMjwJ6Wv7_aU6tAALkPzROcOSM=.d0ee9e97-4348-4441-9c5c-5ab4d834e2bc@github.com>

On Mon, 10 Jun 2024 02:31:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sets the version to 24/24-ea and the copyright year to 2025.
> 
> Content changes related to the start of release (e.g. for removed options in java.1) are handled separately.
> 
> This initial generation also picks up the unpublished changes from: 
> 
> - ~~JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC~~ (covered by merge)
> - JDK-8284500: Typo in Supported Named Extensions - BasicContraints
> - JDK-8324342: Doclet should default `@since` for a nested class to that of its enclosing class
> 
> Thanks

This pull request has now been integrated.

Changeset: 3a01b47a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a01b47ac97714608356ce3faf797c37dc63e9af
Stats:     43 lines in 28 files changed: 2 ins; 3 del; 38 mod

8330205: Initial troff manpage generation for JDK 24

Reviewed-by: alanb, iris

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

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

From cstein at openjdk.org  Tue Jun 11 05:46:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 05:46:16 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
Message-ID: <rxc7-Mprc8iDuw1jhUolYiMoV7l6QxCSbsgnnZ35n1U=.02728f1d-1099-4ec7-a855-1eefe95f90f3@github.com>

On Mon, 10 Jun 2024 20:19:51 GMT, Phil Race <prr at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove double quotes
>
> src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 66:
> 
>> 64: label.size=G&r??e:
>> 65: label.source=&Quelle:
>> 66: label.outputbins=A&usgabef?cher:
> 
> How confident are we in this ?
> google translate says that the old text referred to 'compartments' and the new one to 'areas' and I wonder why that is better ?
> 
> https://translate.google.com/?sl=auto&tl=en&text=Ausgabebereiche%0AAusgebefacher&op=translate

"Ausgabef?cher" is the best German translation here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634221518

From cstein at openjdk.org  Tue Jun 11 05:58:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 05:58:16 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <iJZMTs0UUdFqw07uiMXQrkv3QBeyv70VQyyVZtFy5k4=.22762511-49c4-4ad6-a198-38d2be8ac4f6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
 <ivxoCg1QhjwpzbGR6T6rHreTkqv-NVFo7jZYwNL0LiM=.c10bee70-9ca8-4db5-89b1-ee7682729e3d@github.com>
 <iJZMTs0UUdFqw07uiMXQrkv3QBeyv70VQyyVZtFy5k4=.22762511-49c4-4ad6-a198-38d2be8ac4f6@github.com>
Message-ID: <Fb3AmUHDf5U2lnnok2LqxzKxUuXMQia6Ui9uU-eoqlY=.416d5ef4-d6ca-4aa3-a248-891d0e4b509e@github.com>

On Mon, 10 Jun 2024 22:48:13 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 325:
>> 
>>> 323:         {"Unexpected event type", "Unerwarteter Ereignistyp: {0}"},
>>> 324:         {"unknown", "unbekannt"},
>>> 325:         {"Unmonitoring", "Monitoring von {0} aufheben"},
>> 
>> The English entry is:
>> 
>>         {"Unmonitoring", "Unmonitoring {0} "},
>> 
>> But the German entry now says "Monitoring". I'm  sure what the original "\u00DCberwachung" translates to, other than berwachung is monitoring. Now this resource is partly in English, and is the incorrect English.
>
> I don't know German, but when plugging `"Monitoring von {0} aufheben"` into google translate, I get `Unmonitoring` as well. Maybe `Monitoring` is a word that could also be used in German? No clue. The translation tool decided to make this change.
> 
> @sormuras do you have any input on this?

It's correct.

The "Un" of "Unmonitoring" is moved to the associated verb in German: "aufheben". which in this context translates to "cancel" or "revoke". This seems to be one of the few cases where there's no commonly used single word in German for "Unmonitoring".

> Now this resource is partly in English, and is the incorrect English.

That's how Tech-German often works - take a word from English and use it as-is, sometimes missing the original meaning. Such words or phrases are then referred to as: Denglisch.

In this case "?berwachung" was German, "Monitoring" is Denglisch. I'd revert that to `\u00DCberwachung` - but both are okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634236406

From cstein at openjdk.org  Tue Jun 11 06:03:20 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 06:03:20 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <rxc7-Mprc8iDuw1jhUolYiMoV7l6QxCSbsgnnZ35n1U=.02728f1d-1099-4ec7-a855-1eefe95f90f3@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
 <rxc7-Mprc8iDuw1jhUolYiMoV7l6QxCSbsgnnZ35n1U=.02728f1d-1099-4ec7-a855-1eefe95f90f3@github.com>
Message-ID: <fjDM8CLc7UlLywSpW23R_oXriwUiQu6lPv9zulRvfUs=.3d7a5920-67d3-4270-a366-79df33e241ae@github.com>

On Tue, 11 Jun 2024 05:43:12 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties line 66:
>> 
>>> 64: label.size=G&r??e:
>>> 65: label.source=&Quelle:
>>> 66: label.outputbins=A&usgabef?cher:
>> 
>> How confident are we in this ?
>> google translate says that the old text referred to 'compartments' and the new one to 'areas' and I wonder why that is better ?
>> 
>> https://translate.google.com/?sl=auto&tl=en&text=Ausgabebereiche%0AAusgebefacher&op=translate
>
> "Ausgabef?cher" is the best German translation here.

The reason for going with "Bereich (area)" instead of "Fach (compartment)" is that an area is more general compared to a compartment. At least in German: every "Fach" is a "Bereich", but every "Bereich" is NOT a "Fach".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634240847

From cstein at openjdk.org  Tue Jun 11 06:07:16 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 06:07:16 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <2-SMv3j3Eqrv7LVV6CbkZVEb3KFcahQR1_8AiJErDAQ=.07538bd6-9b25-45ed-b47f-8e9102ea8af9@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <SjpwOVwkqCFBlC_Vj1rv4JwgHdgqnpiz8xrDTE98eOc=.c90d5753-0206-48e9-bfb4-8e6bc67c616a@github.com>
 <2-SMv3j3Eqrv7LVV6CbkZVEb3KFcahQR1_8AiJErDAQ=.07538bd6-9b25-45ed-b47f-8e9102ea8af9@github.com>
Message-ID: <CouuebhtcqMA6bHarrhzi4OkzoYr9fc13nWk21wQjZQ=.00f0f569-3215-4f99-8f00-59d1e7314c44@github.com>

On Mon, 10 Jun 2024 20:34:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 409:
>> 
>>> 407: compiler.err.unconditional.pattern.and.default=Switch umfasst sowohl ein nicht bedingtes Muster als auch ein Standardlabel
>>> 408: 
>>> 409: compiler.err.unconditional.pattern.and.both.boolean.values=Switch umfasst sowohl boolesche Werte als auch ein nicht bedingtes Muster
>> 
>> Here and elsewhere in this file and other translations, I'm surprised `switch` is not being translated, and is being capitalized. In the English form, it is not being used as a keyword, although could maybe be seen as a short form of `switch' statement, in which case `switch` should be treated as a keyword and not translated or capitalized.
>
> Good catch. Seems to be across all files and I'm assuming it's for the reason you suggested. I'll bring this up to the go team. I have no way to fix this since I can't rely on google translate. This can be caught in a future update if the go team can successfully differentiate the difference between the word `switch` and a `switch keyword`.

Yes. "Switch ..." is the short form for "Das Switch-Statement ..." or "Das `switch` Statement ..." and all other longer forms that match the context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634244985

From cstein at openjdk.org  Tue Jun 11 06:13:24 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 11 Jun 2024 06:13:24 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
Message-ID: <oF6N81khTgiBZPXZgBwJUPmJYlcJZF_DD6eIHaTW-Ng=.25effa3a-097e-41a0-bb03-d520fe0013d2@github.com>

On Sun, 9 Jun 2024 19:35:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove double quotes
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 285:
> 
>> 283: VIRTUAL_MACHINE=Virtuelle Maschine
>> 284: VM_ARGUMENTS=VM-Argumente
>> 285: VMINTERNAL_FRAME_ACCESSIBLE_DESCRIPTION=Innerer Frame f?r das Monitoring einer Java Virtual Machine
> 
> This one-off change is consistent with the change in _src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java_.

Consistently changed to be "[Denglisch](https://en.wikipedia.org/wiki/Denglisch)" instead of German.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1634249847

From prappo at openjdk.org  Tue Jun 11 11:06:17 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Jun 2024 11:06:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
Message-ID: <zuNDuUKk1vjisadTmYy9ejFqSmDKWLvKoFY-umQC7IU=.20b7ac6e-a91a-4c13-8c2d-17d2d23002be@github.com>

On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double quotes

I was asked to have a look at this PR elsewhere. I cannot verify correctness of translation, but I can review this PR generally for `jdk.javadoc`.

>From what I can see, the changes are only to the property files, which is expected from the PR title. The keys from English files 1-1 match the keys from non-English files: there are no missing or extra keys.

>From that point of view, the changes to `jdk.javadoc` look good.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2110098592

From naoto at openjdk.org  Tue Jun 11 17:18:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Jun 2024 17:18:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
Message-ID: <IkCDImPZqMUO8lTSYmq1eVu9VujFF-F5D4-gt7Hbt5A=.173876cd-1a2f-4713-a277-5a1cd5ee9703@github.com>

On Mon, 10 Jun 2024 19:45:14 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties line 278:
>> 
>>> 276:         UndeclaredElementInContentSpec = Contentmodell des Elements "{0}" verweist auf das nicht deklarierte Element "{1}".
>>> 277:         UniqueNotationName = Deklaration f?r die Notation "{0}" ist nicht eindeutig. Ein jeweiliger Name darf nicht in mehreren Notationsdeklarationen deklariert werden.
>>> 278:         ENTITYFailedInitializeGrammar =  ENTITYDatatype-Validator: Nicht erfolgreich. Initialisierungsmethode muss mit einer g?ltigen Grammatikreferenz aufgerufen werden. \t
>> 
>> It looks like the _zh_CN_ file should also have the `\t` removed, but such changes are done by the translation tool. I think in this case, we should manually remove it, and then file a bug against the translation tool.
>
> Yeah, I believe you're right. Noted as something else to file against the translation tool.

Just out of curiosity, do we know why `\t` was attached in the first place? I don't think it is with the original English properties.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1635231459

From jlu at openjdk.org  Tue Jun 11 17:26:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Jun 2024 17:26:18 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <IkCDImPZqMUO8lTSYmq1eVu9VujFF-F5D4-gt7Hbt5A=.173876cd-1a2f-4713-a277-5a1cd5ee9703@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <IkCDImPZqMUO8lTSYmq1eVu9VujFF-F5D4-gt7Hbt5A=.173876cd-1a2f-4713-a277-5a1cd5ee9703@github.com>
Message-ID: <dwTM7lAxBa_Z6Diij907FtLkAiNb8Nbc0B2ZLYYIWVY=.df8c37f4-2e21-496c-bba9-29bc71d24689@github.com>

On Tue, 11 Jun 2024 17:15:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Yeah, I believe you're right. Noted as something else to file against the translation tool.
>
> Just out of curiosity, do we know why `\t` was attached in the first place? I don't think it is with the original English properties.

I can see that in 2012, the original did not have `\t` while the translated files did. (Did not search before then).
Seems like this discrepancy originates from awhile ago.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1635242656

From cjplummer at openjdk.org  Tue Jun 11 18:04:42 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 11 Jun 2024 18:04:42 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RMYfMzeTjSTgC0E5UhO44fJsnjtjn7JaokyIswpzljg=.ae3644a2-376e-4249-8a6b-8b02306b5aba@github.com>
Message-ID: <ingMGDOjflPwzkCCYc6MKKiBsXikH9L11Bt_l18MALc=.5726d2a9-d503-45de-a657-becc134c7596@github.com>

On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove double quotes

jdk.jconsole and jdk.jdi changes look fine.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2111108012

From dnguyen at openjdk.org  Tue Jun 11 19:21:17 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Jun 2024 19:21:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v2]
In-Reply-To: <fjDM8CLc7UlLywSpW23R_oXriwUiQu6lPv9zulRvfUs=.3d7a5920-67d3-4270-a366-79df33e241ae@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
 <rxc7-Mprc8iDuw1jhUolYiMoV7l6QxCSbsgnnZ35n1U=.02728f1d-1099-4ec7-a855-1eefe95f90f3@github.com>
 <fjDM8CLc7UlLywSpW23R_oXriwUiQu6lPv9zulRvfUs=.3d7a5920-67d3-4270-a366-79df33e241ae@github.com>
Message-ID: <jbO8ccEzKKoAo9tNxRdfAaMeuN2A_18Qk_c19bJvg0o=.3b33dc8a-d611-4fdb-96e3-d513913d71aa@github.com>

On Tue, 11 Jun 2024 06:00:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> "Ausgabef?cher" is the best German translation here.
>
> The reason for going with "Bereich (area)" instead of "Fach (compartment)" is that an area is more general compared to a compartment. At least in German: every "Fach" is a "Bereich", but every "Bereich" is NOT a "Fach".

Thanks for the input @sormuras!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1635369067

From dnguyen at openjdk.org  Tue Jun 11 19:28:27 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 11 Jun 2024 19:28:27 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Revert updated translation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19609/files
  - new: https://git.openjdk.org/jdk/pull/19609/files/32d69e89..e9e0bcea

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

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

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

From asemenyuk at openjdk.org  Tue Jun 11 20:01:20 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 11 Jun 2024 20:01:20 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
Message-ID: <b4_ag7ODt2hsNNfwRhoSKNQzldRPb-O_DagZiuFMIek=.b56751e1-5385-4a5e-a081-b1818cd30f2a@github.com>

On Tue, 11 Jun 2024 19:28:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert updated translation

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good

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

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2111344874
PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2161509207

From achung at openjdk.org  Tue Jun 11 22:54:19 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 11 Jun 2024 22:54:19 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
Message-ID: <tWMKY1f1KglIZZuTUdD9ZpYS8hmiiIeTv9nytEhFZWE=.201e7860-bc28-4ac4-8812-a8866d1801c1@github.com>

On Tue, 11 Jun 2024 19:28:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert updated translation

LGTM

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

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2111576337

From achung at openjdk.org  Tue Jun 11 22:54:21 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 11 Jun 2024 22:54:21 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <0xmUIRy1V_ts7yyfm1kMaQfbzU5YoJSWAzD3QDNLY7U=.8e0e163e-d0c6-4f22-a92d-79de8c58e8f6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <4SzROPbfO7QDv-6_f_D3ntFvyEpXOvV9vsnb1LNU7Os=.b0fcfbbd-8c54-4443-b06d-722da305490d@github.com>
 <0xmUIRy1V_ts7yyfm1kMaQfbzU5YoJSWAzD3QDNLY7U=.8e0e163e-d0c6-4f22-a92d-79de8c58e8f6@github.com>
Message-ID: <P-vtaJDvvh15Fb-zFtwRbpDSNxovZZXzDiYfFO9Fa0g=.6570cfd3-6cc4-4100-bf53-0f7bd09820fb@github.com>

On Mon, 10 Jun 2024 20:37:41 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties line 32:
>> 
>>> 30: border.jobattributes=????
>>> 31: border.media=??
>>> 32: border.output=??
>> 
>> What triggered this ? Just someone noticing it and deciding there's a better translation ?
>> What does it say ?
>
> In the past, it was brought up in review that some of the words were translated to localized words that didn't exactly mean what the original English word meant. I believe Weijun Wang caught some of these in Chinese files in the past.  I'm assuming these are cases where the go team is improving the translation, but I also can't exactly tell. We do suggest changes to the go team, so maybe this is evidence of them improving their tool.

It was changed from "paper output" to just "output". Since the original English doesn't specify anything about paper, I guess the new translation is more general and fitting in this case.

The original inclusion of the border.output field was actually part of the output bin update on [JDK-8314070](https://bugs.openjdk.org/browse/JDK-8314070) so it was actually not initially translated by the translation team.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1635559474

From achung at openjdk.org  Tue Jun 11 23:13:17 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 11 Jun 2024 23:13:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
Message-ID: <sc34YUtz7xCMiUCtBjFH8Gx9qMQ_6wN20ORFRkBMXZA=.cbdb0a2e-c35a-4a7a-b640-9d1a5dcb62b9@github.com>

On Mon, 10 Jun 2024 20:46:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert updated translation
>
> Did not look at each for translation accuracy (did some for Japanese), but looks good overall.
> It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!

An interesting note after looking at Phil's comment on the serviceui.properties change is that there is no Japanese update for that file. The translations on [here](https://github.com/openjdk/jdk/commit/c7d2a5c1c4e86955100f4c40170dc25222abd07f#diff-38c26a463e174224c6b9fc5007f3058482e533dc0f60f3275e21f9f2fc9acf8e) from the output bins update look good to me but maybe @naotoj should double check in case?

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

PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2161748245

From naoto at openjdk.org  Tue Jun 11 23:29:17 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 11 Jun 2024 23:29:17 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <RdC2DWY9T4c_CtoDC0VQQO-glDmN41Gyjl3ZevJgU5c=.525f206b-ef90-4856-bd4e-e6e0b26822e6@github.com>
Message-ID: <8pnAwewRWdiqnLGBNNUGPwD7bjUsuVhUDtaPC8IJ7Bc=.c7ceb4be-dc7a-48ff-9ee2-7aa3d94b2ead@github.com>

On Mon, 10 Jun 2024 20:46:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert updated translation
>
> Did not look at each for translation accuracy (did some for Japanese), but looks good overall.
> It's great to see diffs in native languages, rather than those cryptic `\uXXXX` notation!

> An interesting note after looking at Phil's comment on the serviceui.properties change is that there is no Japanese update for that file. The translations on [here](https://github.com/openjdk/jdk/commit/c7d2a5c1c4e86955100f4c40170dc25222abd07f#diff-38c26a463e174224c6b9fc5007f3058482e533dc0f60f3275e21f9f2fc9acf8e) from the output bins update look good to me but maybe @naotoj should double check in case?

I can confirm that English "Out&put trays:" to "?????(&P):" is OK

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

PR Comment: https://git.openjdk.org/jdk/pull/19609#issuecomment-2161765683

From prr at openjdk.org  Wed Jun 12 19:46:20 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 12 Jun 2024 19:46:20 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
Message-ID: <vUUnGbZkSBcAhexcNbtiUu-9SzGrvcln2ejWHPLszkg=.2dcd07e7-cb81-4843-84bc-bbd2b84f4a72@github.com>

On Tue, 11 Jun 2024 19:28:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert updated translation

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2114049394

From acobbs at openjdk.org  Wed Jun 12 19:52:15 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 12 Jun 2024 19:52:15 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <t2hbiho3Ir3yrgYEMvUMlLIqVyHNg5pOQyC_bRBeuqE=.63500cde-5841-4d76-b8ec-c16f83d86273@github.com>

On Tue, 14 May 2024 02:00:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

Still looking for a reviewer for this (CSR already approved)... thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/19226#issuecomment-2163785297

From liach at openjdk.org  Wed Jun 12 20:06:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Jun 2024 20:06:16 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <rt4-hFhNIRLJQsUIqBnmUGA38TFNnJsSuFidVrVxATc=.b038c1e5-75ec-4ccb-8dc6-e7fc2cbc784a@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
 <rt4-hFhNIRLJQsUIqBnmUGA38TFNnJsSuFidVrVxATc=.b038c1e5-75ec-4ccb-8dc6-e7fc2cbc784a@github.com>
Message-ID: <crDmo7jTBtVjeVBwW02nh2tXa8ofcVKrFV4qTO2cRpY=.84bbe8e3-1335-455a-af57-af7c4a0fbce7@github.com>

On Fri, 31 May 2024 06:16:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
>> 
>> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.
>
> Sorry for belated reply. This makes sense to me.

Unfortunately we have to defer this to release 24 now, and seems only @lahodaj know about jshell well enough for a review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19226#issuecomment-2163805611

From jlu at openjdk.org  Wed Jun 12 20:15:18 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 12 Jun 2024 20:15:18 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v3]
In-Reply-To: <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <gKEdrkbDjRi0nDWUOKbtoIqqkn704gRuecB9iuFI3qA=.03521c6e-baaf-48aa-a052-c5b9a8cd75d7@github.com>
Message-ID: <xUXJHd1OOUlkCtLwTS_wmgx0FlcrHSE7cbwrmIsCVD4=.b96c0b4a-0028-4d33-8b44-f07b1f1ff039@github.com>

On Tue, 11 Jun 2024 19:28:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>> 
>> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
>> 
>> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
>> https://cr.openjdk.org/~dnguyen/output2/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert updated translation

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/19609#pullrequestreview-2114131181

From dnguyen at openjdk.org  Wed Jun 12 21:11:52 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 12 Jun 2024 21:11:52 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v4]
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <DAEnGganAWoVga2j8IKfI2HiHDrKGn8lHExbWpMzNQU=.e3eea870-10b9-4eca-9cb4-85ee95ed70b3@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Undo translation for some words

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19609/files
  - new: https://git.openjdk.org/jdk/pull/19609/files/e9e0bcea..8c22d1db

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

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

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

From dnguyen at openjdk.org  Wed Jun 12 21:11:52 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 12 Jun 2024 21:11:52 GMT
Subject: RFR: 8333827: JDK 23 RDP1 L10n resource files update [v4]
In-Reply-To: <Ss1KZ4NwolVYPiXv46jXJ05_pDMCkOY4GHYlq5stnCc=.135e6f50-206b-4f75-acf4-4574eaf84951@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
 <6x05vtOnVTgxlyzPvesvYR9v3NUNHNkinbbaXJtXzxU=.492b5e27-02dd-4457-a725-705a3d6be7f9@github.com>
 <wk1BTXn55Ouaqbe_dkzkgpOMsrlIkQVDk5he2qLxgF8=.0ee9ea01-13f5-4c0a-91e2-24cd031eb91e@github.com>
 <06n4CAAdscvysfgXBWG-uWwIUSIt4D_o1wppGATS1II=.7c9a46de-2b24-482b-8f67-77741a7ae938@github.com>
 <8fptu16lcceBUEid012EvN4KHhrf3gjzPRgdOANg_Kk=.4d3d1e78-17f9-4248-89ca-99ca03370e71@github.com>
 <Ss1KZ4NwolVYPiXv46jXJ05_pDMCkOY4GHYlq5stnCc=.135e6f50-206b-4f75-acf4-4574eaf84951@github.com>
Message-ID: <tYq_jOkBddmXa1PV50hifwtXBOKDhobAVEX4PKO7U40=.518cf1f2-8c4f-4789-b51a-fa1bb4b62ccd@github.com>

On Mon, 10 Jun 2024 23:11:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> @jonathan-gibbons I just realized that this change to the German file matches the file with the Japanese and Chinese localized files. By that I mean the "backwards" translations are also present for the Japanese and Chinese files.
>> 
>> However, the previous versions of the Japanese and Chinese files don't have these bits translated. So in summary, I can revert the German file back to German but the Japanese and Chinese files will still be English for these parts because I wouldn't know what to revert them to in their local language.
>> 
>> As a result, I actually think it might be better to change this German file as shown in the current version of the PR just to remain consistent with the other localized versions of this file. We can still bring this up to the go team as an issue, but I think this is the best solution now for this drop at least.
>
> No one else except people reading this PR will spot inconsistencies between translations in different languages. So inconsistencies across languages will not be obvious to end users.
> 
> But anyone (end-user) using the tool in any one of these languages is likely to spot inconsistencies in the translations for that one language.

@jonathan-gibbons I have gone back and manually undid some of the English translations back to its former German word. Most occurrences of this are `<flag>` to `<Kennzeichen>`, but some others were changed back as well. Could you re-review this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19609#discussion_r1637092298

From jlahoda at openjdk.org  Thu Jun 13 14:54:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 13 Jun 2024 14:54:16 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <fNxNDl6-gENwbVwgIANecKElyV6MiHUB4ks6FKAq6lQ=.f29e108e-ed82-4262-8ccf-a52513e0b55f@github.com>

On Tue, 14 May 2024 02:00:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

Makes sense to me. Please note the suggested change to `@since` inline.

src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java line 224:

> 222:      * @param rows number of displayed rows
> 223:      * @return the {@code JavaShellToolBuilder} instance
> 224:      * @since 23

Suggestion:

     * @since 24

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19226#pullrequestreview-2116036351
PR Review Comment: https://git.openjdk.org/jdk/pull/19226#discussion_r1638357582

From acobbs at openjdk.org  Thu Jun 13 16:04:48 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 13 Jun 2024 16:04:48 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface [v2]
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <O5k4gLzrpOcGW-I_BgBSbVP77OESavGTRv9BP7Ohb3g=.c911a1ce-69a7-4eeb-8b1e-2e6dc5078eab@github.com>

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

Archie Cobbs 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 five additional commits since the last revision:

 - Bump @since tag 23 -> 24.
 - Merge branch 'master' into JavaShellToolBuilder.windowSize
 - Update copyright years.
 - Fix typo in exception message.
 - Add new method JavaShellToolBuilder.windowSize().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19226/files
  - new: https://git.openjdk.org/jdk/pull/19226/files/37aa4b8d..39fb0972

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

  Stats: 114940 lines in 2281 files changed: 79530 ins; 25061 del; 10349 mod
  Patch: https://git.openjdk.org/jdk/pull/19226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19226/head:pull/19226

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

From acobbs at openjdk.org  Thu Jun 13 16:04:48 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 13 Jun 2024 16:04:48 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface [v2]
In-Reply-To: <fNxNDl6-gENwbVwgIANecKElyV6MiHUB4ks6FKAq6lQ=.f29e108e-ed82-4262-8ccf-a52513e0b55f@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
 <fNxNDl6-gENwbVwgIANecKElyV6MiHUB4ks6FKAq6lQ=.f29e108e-ed82-4262-8ccf-a52513e0b55f@github.com>
Message-ID: <97DuLbym7UuFj4hf9StvyzWyDOZRFNe6eIkVJS4h8ek=.3aeda123-3705-4f89-aa1e-02431168a55d@github.com>

On Thu, 13 Jun 2024 14:50:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Archie Cobbs 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 five additional commits since the last revision:
>> 
>>  - Bump @since tag 23 -> 24.
>>  - Merge branch 'master' into JavaShellToolBuilder.windowSize
>>  - Update copyright years.
>>  - Fix typo in exception message.
>>  - Add new method JavaShellToolBuilder.windowSize().
>
> src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java line 224:
> 
>> 222:      * @param rows number of displayed rows
>> 223:      * @return the {@code JavaShellToolBuilder} instance
>> 224:      * @since 23
> 
> Suggestion:
> 
>      * @since 24

Thanks - fixed in 39fb097.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19226#discussion_r1638461540

From dnguyen at openjdk.org  Thu Jun 13 21:32:24 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 13 Jun 2024 21:32:24 GMT
Subject: Integrated: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
References: <kBnLJalScsnsCOYxtnGUnxFAkZVP1eWtHxbdRWBCGeM=.98a2eef9-44f2-4f30-b147-ea37a2cd4b59@github.com>
Message-ID: <PHwvH3AGCvU714vSF5eogwl7u7smKE8mEXNNBx_jZHw=.00a7eff2-a020-4ff5-b82f-2a14b33ba35a@github.com>

On Fri, 7 Jun 2024 22:46:44 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK. Primarily, the changes between JDK 22 RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
> 
> The translation tool adjusted some definitions, which causes some changes in localized files where the source file had no changes. This causes some words being reverted from localized languages to English, and some had its definitions changed.
> 
> Alternatively, the diffs are viewable here and was generated using Jonathan Gibbons' diff tool for l10n:
> https://cr.openjdk.org/~dnguyen/output2/

This pull request has now been integrated.

Changeset: c4702ca8
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a
Stats:     237 lines in 38 files changed: 133 ins; 57 del; 47 mod

8333827: JDK 23 RDP1 L10n resource files update

Reviewed-by: achung, jlu, naoto, joehw, prappo, cjplummer, asemenyuk, prr

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

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

From dnguyen at openjdk.org  Thu Jun 13 21:45:37 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 13 Jun 2024 21:45:37 GMT
Subject: [jdk23] RFR: 8333827: JDK 23 RDP1 L10n resource files update
Message-ID: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>

Hi all,

This pull request contains a backport of commit [c4702ca8](https://github.com/openjdk/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Damon Nguyen on 13 Jun 2024 and was reviewed by Alisen Chung, Justin Lu, Naoto Sato, Joe Wang, Pavel Rappo, Chris Plummer, Alexey Semenyuk and Phil Race.

Thanks!

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

Commit messages:
 - Backport c4702ca8c026e2d265aca0126fd3fb7bc5bb392a

Changes: https://git.openjdk.org/jdk/pull/19713/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19713&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333827
  Stats: 237 lines in 38 files changed: 133 ins; 57 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/19713.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19713/head:pull/19713

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

From jlu at openjdk.org  Thu Jun 13 21:45:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 13 Jun 2024 21:45:37 GMT
Subject: [jdk23] RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
References: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
Message-ID: <BElwil0jmH0ze0istvpnHeChiUH_VkQTR2Fpekk6wAc=.b3a49075-4e5b-4819-8f43-698207725e09@github.com>

On Thu, 13 Jun 2024 21:38:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c4702ca8](https://github.com/openjdk/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Damon Nguyen on 13 Jun 2024 and was reviewed by Alisen Chung, Justin Lu, Naoto Sato, Joe Wang, Pavel Rappo, Chris Plummer, Alexey Semenyuk and Phil Race.
> 
> Thanks!

Clean backport of L10n resource drop required for JDK23

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/19713#pullrequestreview-2117082417

From naoto at openjdk.org  Thu Jun 13 21:48:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Jun 2024 21:48:14 GMT
Subject: [jdk23] RFR: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
References: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
Message-ID: <OIOxdjppmbkch2qDdWkZwpdRD9TLTMxAx7pD2fIZVTs=.a99b7fee-5dfc-4b3e-aac5-e524b5888da7@github.com>

On Thu, 13 Jun 2024 21:38:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c4702ca8](https://github.com/openjdk/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Damon Nguyen on 13 Jun 2024 and was reviewed by Alisen Chung, Justin Lu, Naoto Sato, Joe Wang, Pavel Rappo, Chris Plummer, Alexey Semenyuk and Phil Race.
> 
> Thanks!

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19713#pullrequestreview-2117085705

From dnguyen at openjdk.org  Thu Jun 13 21:51:17 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 13 Jun 2024 21:51:17 GMT
Subject: [jdk23] Integrated: 8333827: JDK 23 RDP1 L10n resource files update
In-Reply-To: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
References: <ir-rPjlu15vrBoqjBZPeFbHx4fIwBmhkqTY2Ylt3D54=.501e11b7-9495-4e49-9358-5055e15b1b4d@github.com>
Message-ID: <2L_EtBxkTfdXVo8_kwbYVDyrQb9T5YRNQXwM03orLko=.be85bc8d-836c-49b1-9663-149f79562338@github.com>

On Thu, 13 Jun 2024 21:38:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c4702ca8](https://github.com/openjdk/jdk/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Damon Nguyen on 13 Jun 2024 and was reviewed by Alisen Chung, Justin Lu, Naoto Sato, Joe Wang, Pavel Rappo, Chris Plummer, Alexey Semenyuk and Phil Race.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a7964453
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7964453cf5203229d4a5b5231b7fc86da5d4af8
Stats:     237 lines in 38 files changed: 133 ins; 57 del; 47 mod

8333827: JDK 23 RDP1 L10n resource files update

Reviewed-by: jlu, naoto
Backport-of: c4702ca8c026e2d265aca0126fd3fb7bc5bb392a

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

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

From jlahoda at openjdk.org  Tue Jun 18 12:03:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 18 Jun 2024 12:03:23 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface [v2]
In-Reply-To: <O5k4gLzrpOcGW-I_BgBSbVP77OESavGTRv9BP7Ohb3g=.c911a1ce-69a7-4eeb-8b1e-2e6dc5078eab@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
 <O5k4gLzrpOcGW-I_BgBSbVP77OESavGTRv9BP7Ohb3g=.c911a1ce-69a7-4eeb-8b1e-2e6dc5078eab@github.com>
Message-ID: <D6pwHkOw4g4OqTJq2iSofgbyMdMAH8JCyBaQD1dCwLw=.322d1034-00f9-454d-b70b-70ffec7afa78@github.com>

On Thu, 13 Jun 2024 16:04:48 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
>> 
>> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.
>
> Archie Cobbs 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 five additional commits since the last revision:
> 
>  - Bump @since tag 23 -> 24.
>  - Merge branch 'master' into JavaShellToolBuilder.windowSize
>  - Update copyright years.
>  - Fix typo in exception message.
>  - Add new method JavaShellToolBuilder.windowSize().

Some commands missing in the license header. Sorry for that.

src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java line 2:

> 1: /*
> 2:  * Copyright (c) 2016, 2024 Oracle and/or its affiliates. All rights reserved.

(Assuming the header is intended:) there must be a comma after the year (i.e. `2024,` instead of `2024`).

src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java line 2:

> 1: /*
> 2:  * Copyright (c) 2016, 2024 Oracle and/or its affiliates. All rights reserved.

(Assuming the header is intended:) there must be a comma after the year (i.e. `2024,` instead of `2024`).

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

Changes requested by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19226#pullrequestreview-2125326208
PR Review Comment: https://git.openjdk.org/jdk/pull/19226#discussion_r1644347181
PR Review Comment: https://git.openjdk.org/jdk/pull/19226#discussion_r1644347737

From acobbs at openjdk.org  Tue Jun 18 16:24:02 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 18 Jun 2024 16:24:02 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface [v3]
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <JODApIleN9c7RNJm5w_FEMXfX9l1cwTHTY2ynocYDkk=.e8776b18-45ab-4f2a-ac50-7e7824bf1310@github.com>

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Copyright years should be followed by a comma.
 - Merge branch 'master' into JavaShellToolBuilder.windowSize
 - Bump @since tag 23 -> 24.
 - Merge branch 'master' into JavaShellToolBuilder.windowSize
 - Update copyright years.
 - Fix typo in exception message.
 - Add new method JavaShellToolBuilder.windowSize().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19226/files
  - new: https://git.openjdk.org/jdk/pull/19226/files/39fb0972..1769df6d

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

  Stats: 2149 lines in 111 files changed: 1653 ins; 180 del; 316 mod
  Patch: https://git.openjdk.org/jdk/pull/19226.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19226/head:pull/19226

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

From acobbs at openjdk.org  Tue Jun 18 16:24:05 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 18 Jun 2024 16:24:05 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface [v2]
In-Reply-To: <D6pwHkOw4g4OqTJq2iSofgbyMdMAH8JCyBaQD1dCwLw=.322d1034-00f9-454d-b70b-70ffec7afa78@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
 <O5k4gLzrpOcGW-I_BgBSbVP77OESavGTRv9BP7Ohb3g=.c911a1ce-69a7-4eeb-8b1e-2e6dc5078eab@github.com>
 <D6pwHkOw4g4OqTJq2iSofgbyMdMAH8JCyBaQD1dCwLw=.322d1034-00f9-454d-b70b-70ffec7afa78@github.com>
Message-ID: <z6WlNn3qBq75BaKqNnEqWrkHfabciTuFZ6nUcYbkiAc=.7b8d5dff-9f15-427c-b5ad-46e1139546be@github.com>

On Tue, 18 Jun 2024 12:00:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Archie Cobbs 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 five additional commits since the last revision:
>> 
>>  - Bump @since tag 23 -> 24.
>>  - Merge branch 'master' into JavaShellToolBuilder.windowSize
>>  - Update copyright years.
>>  - Fix typo in exception message.
>>  - Add new method JavaShellToolBuilder.windowSize().
>
> src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2016, 2024 Oracle and/or its affiliates. All rights reserved.
> 
> (Assuming the header is intended:) there must be a comma after the year (i.e. `2024,` instead of `2024`).

Thanks - fixed in 1769df6.

> src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2016, 2024 Oracle and/or its affiliates. All rights reserved.
> 
> (Assuming the header is intended:) there must be a comma after the year (i.e. `2024,` instead of `2024`).

Thanks - fixed in 1769df6.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19226#discussion_r1644746518
PR Review Comment: https://git.openjdk.org/jdk/pull/19226#discussion_r1644746629

From jlahoda at openjdk.org  Thu Jun 20 11:49:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 20 Jun 2024 11:49:13 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface [v3]
In-Reply-To: <JODApIleN9c7RNJm5w_FEMXfX9l1cwTHTY2ynocYDkk=.e8776b18-45ab-4f2a-ac50-7e7824bf1310@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
 <JODApIleN9c7RNJm5w_FEMXfX9l1cwTHTY2ynocYDkk=.e8776b18-45ab-4f2a-ac50-7e7824bf1310@github.com>
Message-ID: <Fat4EzsleSndTKSRkfSeaPx07WSo1nutdp9HiNB066g=.f85df3de-3cb9-4147-94e7-6cfe68cc9a2f@github.com>

On Tue, 18 Jun 2024 16:24:02 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
>> 
>> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Copyright years should be followed by a comma.
>  - Merge branch 'master' into JavaShellToolBuilder.windowSize
>  - Bump @since tag 23 -> 24.
>  - Merge branch 'master' into JavaShellToolBuilder.windowSize
>  - Update copyright years.
>  - Fix typo in exception message.
>  - Add new method JavaShellToolBuilder.windowSize().

Looks good, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19226#pullrequestreview-2130205821

From acobbs at openjdk.org  Thu Jun 20 14:47:14 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 20 Jun 2024 14:47:14 GMT
Subject: RFR: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface [v3]
In-Reply-To: <JODApIleN9c7RNJm5w_FEMXfX9l1cwTHTY2ynocYDkk=.e8776b18-45ab-4f2a-ac50-7e7824bf1310@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
 <JODApIleN9c7RNJm5w_FEMXfX9l1cwTHTY2ynocYDkk=.e8776b18-45ab-4f2a-ac50-7e7824bf1310@github.com>
Message-ID: <PtSsG_fOvAWtWd2zbPSJiQyt7XfsSJhgLXYhIVWqxhI=.12a0cfb7-2ec3-4c24-8210-c589697eafbf@github.com>

On Tue, 18 Jun 2024 16:24:02 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
>> 
>> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Copyright years should be followed by a comma.
>  - Merge branch 'master' into JavaShellToolBuilder.windowSize
>  - Bump @since tag 23 -> 24.
>  - Merge branch 'master' into JavaShellToolBuilder.windowSize
>  - Update copyright years.
>  - Fix typo in exception message.
>  - Add new method JavaShellToolBuilder.windowSize().

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19226#issuecomment-2180890958

From acobbs at openjdk.org  Fri Jun 21 10:47:14 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 21 Jun 2024 10:47:14 GMT
Subject: Integrated: 8332314: Add window size configuration option to
 JavaShellToolBuilder interface
In-Reply-To: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
References: <SQUlMXslAwSek7P697JnYvmAltlL1FUta1VQoBOUhcc=.68b7151a-e002-4111-ad5f-2b6b6ce1a44e@github.com>
Message-ID: <ivKAVUwsl568X7Yx0vJXPzLnsYg8dShsert9YRjvbHE=.f24281db-38d3-47c4-add1-bc10ff919355@github.com>

On Tue, 14 May 2024 02:00:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> When launching JShell programmatically (i.e., from a Java program instead of the command line) for an interactive session, it's not currently possible to inform JShell what the terminal window's dimensions are. As a result, JShell defaults to 80x24 and line editing becomes almost impossible because of the scrambled screen contents unless you happen to be using an 80x24 window, which these days is very unlikely.
> 
> This patch adds a new method `JavaShellToolBuilder.windowSize()` which allows passing a "hint" for the number of rows & columns.

This pull request has now been integrated.

Changeset: 08ace27d
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08ace27da1d9cd215c77471eabf41417ff6282d2
Stats:     46 lines in 4 files changed: 35 ins; 1 del; 10 mod

8332314: Add window size configuration option to JavaShellToolBuilder interface

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.org  Fri Jun 21 13:49:36 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 21 Jun 2024 13:49:36 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
Message-ID: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>

JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.

We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.

The proposal herein is twofold:
- disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
- make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.

I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.

@MBaesken, please let me know what you think of this change.

I would like to backport this to JDK 23.

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

Commit messages:
 - 8334433: jshell.exe runs an executable test.exe on startup

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

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

From mbaesken at openjdk.org  Fri Jun 21 15:07:10 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Jun 2024 15:07:10 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
In-Reply-To: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
Message-ID: <UkMJ-5GBtG0x4H3q5ZDL9SFNp67skwXZfG2bhPCq4qA=.5749d010-f9cd-4a54-8a8f-bc3c680a4c72@github.com>

On Fri, 21 Jun 2024 13:45:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
> 
> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
> 
> The proposal herein is twofold:
> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
> 
> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
> 
> @MBaesken, please let me know what you think of this change.
> 
> I would like to backport this to JDK 23.

I put this PR into our build/test queues .

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

PR Comment: https://git.openjdk.org/jdk/pull/19828#issuecomment-2182926791

From jpai at openjdk.org  Sun Jun 23 04:23:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 23 Jun 2024 04:23:15 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
In-Reply-To: <JY7mlzHmtw2Bzypz2xJ6J3dK7IBtYeJF8byOzBjW9tc=.63f8d530-2241-433f-a5bf-5cf76b75c2a4@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <JY7mlzHmtw2Bzypz2xJ6J3dK7IBtYeJF8byOzBjW9tc=.63f8d530-2241-433f-a5bf-5cf76b75c2a4@github.com>
Message-ID: <wHIAXs75-zVQTzhkqBhc3DnUzCqXQppm_-KNwuDCRbk=.30043de3-209c-4e82-9b6b-903938989ead@github.com>

On Sun, 23 Jun 2024 04:18:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
>> 
>> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
>> 
>> The proposal herein is twofold:
>> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
>> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
>> 
>> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
>> 
>> @MBaesken, please let me know what you think of this change.
>> 
>> I would like to backport this to JDK 23.
>
> test/langtools/jdk/jshell/TerminalNoExecTest.java line 68:
> 
>> 66:                 System.exit(1);
>> 67:             }
>> 68:             System.exit(0);
> 
> Hello Jan, calling `System.exit()` from within the jtreg test isn't recommended as noted in https://openjdk.org/jtreg/faq.html#should-a-test-call-the-system.exit-method. Just throwing a exception should fail the test here - something like `throw new AssertionError("jshell unexpectedly spawned a new process");`

Please ignore my previous comment. I now see what's being done here - although this is a jtreg test class, the test itself launches this class as a main application through `ProcessBuilder` and it's only in that flow that the `System.exit(...)` gets called. I think that is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19828#discussion_r1649895405

From jpai at openjdk.org  Sun Jun 23 04:23:14 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 23 Jun 2024 04:23:14 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
In-Reply-To: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
Message-ID: <JY7mlzHmtw2Bzypz2xJ6J3dK7IBtYeJF8byOzBjW9tc=.63f8d530-2241-433f-a5bf-5cf76b75c2a4@github.com>

On Fri, 21 Jun 2024 13:45:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
> 
> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
> 
> The proposal herein is twofold:
> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
> 
> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
> 
> @MBaesken, please let me know what you think of this change.
> 
> I would like to backport this to JDK 23.

test/langtools/jdk/jshell/TerminalNoExecTest.java line 68:

> 66:                 System.exit(1);
> 67:             }
> 68:             System.exit(0);

Hello Jan, calling `System.exit()` from within the jtreg test isn't recommended as noted in https://openjdk.org/jtreg/faq.html#should-a-test-call-the-system.exit-method. Just throwing a exception should fail the test here - something like `throw new AssertionError("jshell unexpectedly spawned a new process");`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19828#discussion_r1649895219

From jpai at openjdk.org  Sun Jun 23 04:26:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 23 Jun 2024 04:26:13 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
In-Reply-To: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
Message-ID: <Na-cwETZGSRGDowxXu8lWaPjsAESSCVVXz-Sh4P29Go=.d59a9d18-680a-46bd-a5d6-8c5827294dc7@github.com>

On Fri, 21 Jun 2024 13:45:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
> 
> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
> 
> The proposal herein is twofold:
> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
> 
> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
> 
> @MBaesken, please let me know what you think of this change.
> 
> I would like to backport this to JDK 23.

test/langtools/jdk/jshell/TerminalNoExecTest.java line 86:

> 84:                         .start();
> 85: 
> 86:             if (!target.waitFor(1, TimeUnit.MINUTES)) {

It might be better to just `waitFor()` without a timeout here. That way the jtreg and the execution environment can timeout the test and capture any necessary diagnostics if the process doesn't terminate for any reason. That also removes the need to decide what the suitable timeout value should be for `waitFor(...)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19828#discussion_r1649895652

From jlahoda at openjdk.org  Tue Jun 25 12:00:11 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Jun 2024 12:00:11 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
In-Reply-To: <wHIAXs75-zVQTzhkqBhc3DnUzCqXQppm_-KNwuDCRbk=.30043de3-209c-4e82-9b6b-903938989ead@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <JY7mlzHmtw2Bzypz2xJ6J3dK7IBtYeJF8byOzBjW9tc=.63f8d530-2241-433f-a5bf-5cf76b75c2a4@github.com>
 <wHIAXs75-zVQTzhkqBhc3DnUzCqXQppm_-KNwuDCRbk=.30043de3-209c-4e82-9b6b-903938989ead@github.com>
Message-ID: <NAmhUgHVDs9yDBNTl6FcBhlQO1AzgB5VdsyxmxmhkU4=.0e976b92-5fa5-45e8-8317-6b17306a91e7@github.com>

On Sun, 23 Jun 2024 04:20:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/langtools/jdk/jshell/TerminalNoExecTest.java line 68:
>> 
>>> 66:                 System.exit(1);
>>> 67:             }
>>> 68:             System.exit(0);
>> 
>> Hello Jan, calling `System.exit()` from within the jtreg test isn't recommended as noted in https://openjdk.org/jtreg/faq.html#should-a-test-call-the-system.exit-method. Just throwing a exception should fail the test here - something like `throw new AssertionError("jshell unexpectedly spawned a new process");`
>
> Please ignore my previous comment. I now see what's being done here - although this is a jtreg test class, the test itself launches this class as a main application through `ProcessBuilder` and it's only in that flow that the `System.exit(...)` gets called. I think that is fine.

FWIW, the reason to start another process is that we need (more) control over the stdin/stdout here, which is not (I think) possible using jtreg. Hence we fork a new process, that performs the real test. The test is still somewhat fragile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19828#discussion_r1652668354

From jlahoda at openjdk.org  Tue Jun 25 12:38:26 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Jun 2024 12:38:26 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
 [v2]
In-Reply-To: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
Message-ID: <Gc2Rad_PTIBiNrP7iGcQM0b916OHKv_R7kK4DEScdT4=.85168d47-2c6c-490a-8757-f74a91d956e8@github.com>

> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
> 
> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
> 
> The proposal herein is twofold:
> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
> 
> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
> 
> @MBaesken, please let me know what you think of this change.
> 
> I would like to backport this to JDK 23.

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

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19828/files
  - new: https://git.openjdk.org/jdk/pull/19828/files/a6aef9ff..1e6f2e3f

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

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

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

From jpai at openjdk.org  Tue Jun 25 14:10:19 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 14:10:19 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
 [v2]
In-Reply-To: <NAmhUgHVDs9yDBNTl6FcBhlQO1AzgB5VdsyxmxmhkU4=.0e976b92-5fa5-45e8-8317-6b17306a91e7@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <JY7mlzHmtw2Bzypz2xJ6J3dK7IBtYeJF8byOzBjW9tc=.63f8d530-2241-433f-a5bf-5cf76b75c2a4@github.com>
 <wHIAXs75-zVQTzhkqBhc3DnUzCqXQppm_-KNwuDCRbk=.30043de3-209c-4e82-9b6b-903938989ead@github.com>
 <NAmhUgHVDs9yDBNTl6FcBhlQO1AzgB5VdsyxmxmhkU4=.0e976b92-5fa5-45e8-8317-6b17306a91e7@github.com>
Message-ID: <uUlgfELEP4Nt1NkkP6bOv0dkSQyyZZbOWcEJWG-_YA8=.2e3c448f-7654-4d01-ad19-1aed97d8626d@github.com>

On Tue, 25 Jun 2024 11:57:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Please ignore my previous comment. I now see what's being done here - although this is a jtreg test class, the test itself launches this class as a main application through `ProcessBuilder` and it's only in that flow that the `System.exit(...)` gets called. I think that is fine.
>
> FWIW, the reason to start another process is that we need (more) control over the stdin/stdout here, which is not (I think) possible using jtreg. Hence we fork a new process, that performs the real test. The test is still somewhat fragile.

Launching of a new `java` application from within the jtreg test is fine and is done in several places. What confused me was that the test was launching the test class itself as an application. I don't know if it's a convention, but I usually have a separate nested `public class FooBarWhatever`  within the test class which I launch using the ProcessBuilder as `Test$FooBarWhatever` and have the application logic reside in the main() method of `FooBarWhatever`. 

I am not expecting that you change the PR to do it that way though. Once I spent a few seconds on that code, it was clear what it was doing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19828#discussion_r1652890544

From jpai at openjdk.org  Tue Jun 25 14:16:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Jun 2024 14:16:13 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
 [v2]
In-Reply-To: <Gc2Rad_PTIBiNrP7iGcQM0b916OHKv_R7kK4DEScdT4=.85168d47-2c6c-490a-8757-f74a91d956e8@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <Gc2Rad_PTIBiNrP7iGcQM0b916OHKv_R7kK4DEScdT4=.85168d47-2c6c-490a-8757-f74a91d956e8@github.com>
Message-ID: <TKpxyV94YX2_mpNnGew8Idr9CfqwJGQSPPMc9QRpu5s=.a0145c41-20fa-49fd-bb74-56fd3365a17f@github.com>

On Tue, 25 Jun 2024 12:38:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
>> 
>> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
>> 
>> The proposal herein is twofold:
>> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
>> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
>> 
>> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
>> 
>> @MBaesken, please let me know what you think of this change.
>> 
>> I would like to backport this to JDK 23.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Hello Jan,
The changes look OK to me. This now prevents launching (potentially) arbitrary processes when launching jshell on platforms where we have FFM support. 

For AIX systems, like you note, we would need inputs from someone from AIX if this change is OK. Especially, the part where we have hardcoded the paths to `/usr/bin` and `/bin` - I don't know if those are applicable for AIX or something else would be needed.

Matthias has noted in this PR that he has included this change in their build queue, but the newly introduced test is not configured to run on AIX, so I'm not sure if it would catch a regression. Do you think any manual testing would need to be done by Matthias to verify those paths work fine?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19828#pullrequestreview-2138809842

From jlahoda at openjdk.org  Tue Jun 25 14:39:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 25 Jun 2024 14:39:15 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v4]
In-Reply-To: <vUHlyUETNoun_Tr-aBZurgBZ8AMN9u8gxZM63JNJpEQ=.3569ac3d-b9b2-4473-a9c7-081ab27b1c8e@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <vUHlyUETNoun_Tr-aBZurgBZ8AMN9u8gxZM63JNJpEQ=.3569ac3d-b9b2-4473-a9c7-081ab27b1c8e@github.com>
Message-ID: <zwdko3eKZIRozu98X2qUIYxfUbSMxdg3mcFFjIvhlAs=.78ec3e56-f951-4cec-af13-0d48dd1f0781@github.com>

On Thu, 6 Jun 2024 16:56:53 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

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

To me, looks good. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18383#pullrequestreview-2138899219

From jlahoda at openjdk.org  Wed Jun 26 10:07:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Jun 2024 10:07:13 GMT
Subject: RFR: 8332014: since-checker - Fix @ since tags in jdk.jshell [v2]
In-Reply-To: <BIkUHfaQncAbpj_gqToVnwqZfwcoPdkXM2VdYtEBSzU=.43cd78a2-79fd-4d35-b3e9-6e1693c30bc7@github.com>
References: <EEVWpO4_ntUkpN3GbUMBSKPJ5q9KPCEQmFazVlNecTc=.97af6015-1c8a-4a9f-b869-a99adfaa979a@github.com>
 <BIkUHfaQncAbpj_gqToVnwqZfwcoPdkXM2VdYtEBSzU=.43cd78a2-79fd-4d35-b3e9-6e1693c30bc7@github.com>
Message-ID: <PvQMYrUGUwD8PuWWPq1vk47QRUdKAtjmlr1Mxg-YUvY=.cf3910bc-402a-477d-bb2c-097866e66803@github.com>

On Fri, 10 May 2024 02:25:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

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

Looks good to me. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19166#pullrequestreview-2141340529

From nbenalla at openjdk.org  Wed Jun 26 10:10:14 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 26 Jun 2024 10:10:14 GMT
Subject: RFR: 8332014: since-checker - Fix @ since tags in jdk.jshell [v2]
In-Reply-To: <BIkUHfaQncAbpj_gqToVnwqZfwcoPdkXM2VdYtEBSzU=.43cd78a2-79fd-4d35-b3e9-6e1693c30bc7@github.com>
References: <EEVWpO4_ntUkpN3GbUMBSKPJ5q9KPCEQmFazVlNecTc=.97af6015-1c8a-4a9f-b869-a99adfaa979a@github.com>
 <BIkUHfaQncAbpj_gqToVnwqZfwcoPdkXM2VdYtEBSzU=.43cd78a2-79fd-4d35-b3e9-6e1693c30bc7@github.com>
Message-ID: <FiKah5naBxlqAanCg_QsZbZYNLRofGtlf-CeLa-POvM=.a7ddad46-194d-4ffd-b6cd-6759ba23f6d4@github.com>

On Fri, 10 May 2024 02:25:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

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

Thank you for the review Jan!

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

PR Comment: https://git.openjdk.org/jdk/pull/19166#issuecomment-2191313971

From hgreule at openjdk.org  Wed Jun 26 12:33:13 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 26 Jun 2024 12:33:13 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v4]
In-Reply-To: <vUHlyUETNoun_Tr-aBZurgBZ8AMN9u8gxZM63JNJpEQ=.3569ac3d-b9b2-4473-a9c7-081ab27b1c8e@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <vUHlyUETNoun_Tr-aBZurgBZ8AMN9u8gxZM63JNJpEQ=.3569ac3d-b9b2-4473-a9c7-081ab27b1c8e@github.com>
Message-ID: <b6qJC8qn3GEqOEz6jF-gbJLV2G2D167HGDfbooG6Ymk=.8c84d8b0-9f94-4511-b609-246516051383@github.com>

On Thu, 6 Jun 2024 16:56:53 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

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

Thanks for the review.

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

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

From liach at openjdk.org  Wed Jun 26 23:20:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Jun 2024 23:20:15 GMT
Subject: RFR: 8328536: javac - crash on unknown type referenced in yield
 statement [v4]
In-Reply-To: <vUHlyUETNoun_Tr-aBZurgBZ8AMN9u8gxZM63JNJpEQ=.3569ac3d-b9b2-4473-a9c7-081ab27b1c8e@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
 <vUHlyUETNoun_Tr-aBZurgBZ8AMN9u8gxZM63JNJpEQ=.3569ac3d-b9b2-4473-a9c7-081ab27b1c8e@github.com>
Message-ID: <zVekBwUvn1vx_YaExDB8_fHbeKNeHOWTXppgceopn0A=.13e94ed2-7d37-4000-8b59-86689c4e65ac@github.com>

On Thu, 6 Jun 2024 16:56:53 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

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

langtools tier 1+2 tests pass.

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

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

From hgreule at openjdk.org  Wed Jun 26 23:20:16 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 26 Jun 2024 23:20:16 GMT
Subject: Integrated: 8328536: javac - crash on unknown type referenced in yield
 statement
In-Reply-To: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
References: <Oij9ry7MEEZRDVCh4k1GCBFltJLRHFj4UfHOZWgZSPc=.2e5498ce-5a81-4114-99d3-df3adcf4cef4@github.com>
Message-ID: <RFmrjRjjQvKHYssg1PdmI7a3FggO80AKekVS9EzME8o=.8be248c2-f77d-4b3c-b7ed-1b560b83818f@github.com>

On Tue, 19 Mar 2024 17:49:32 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Pasting  e.g.
> 
> I m(I i, int x) {
>    return switch (x) {
>         default -> i;
>    };
> }
> 
> in jshell will cause a crash if `I` is not declared already. This comes down to javac not creating an error type for the value of the (implicit) yield from the switch.
> 
> Javac will not crash but swallow the exception, and create a file containing the command line options.
> 
> I first thought about just checking for null of the type here https://github.com/openjdk/jdk/blob/9ca4ae3d3b746f1d75036d189ff98f02b73b948f/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L1640 but after a closer look, the `checkIdInternal` method seems a better fit, as it also updates the type normally.

This pull request has now been integrated.

Changeset: 3796fdfc
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3796fdfcedc2b2202b72cca062218f840960414c
Stats:     54 lines in 6 files changed: 47 ins; 3 del; 4 mod

8328536: javac - crash on unknown type referenced in yield statement

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: jlahoda

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

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

From nbenalla at openjdk.org  Thu Jun 27 06:25:16 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Jun 2024 06:25:16 GMT
Subject: Integrated: 8332014: since-checker - Fix @ since tags in jdk.jshell
In-Reply-To: <EEVWpO4_ntUkpN3GbUMBSKPJ5q9KPCEQmFazVlNecTc=.97af6015-1c8a-4a9f-b869-a99adfaa979a@github.com>
References: <EEVWpO4_ntUkpN3GbUMBSKPJ5q9KPCEQmFazVlNecTc=.97af6015-1c8a-4a9f-b869-a99adfaa979a@github.com>
Message-ID: <oo3BbCDCJcAfkmJuAuGBTzmbC_lcb6yGK_bKj05ZEjg=.2d8c94dc-aa82-4153-8758-4f0f17111e29@github.com>

On Fri, 10 May 2024 01:51:06 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 0fc5b271
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0fc5b2711fbdde972c40bfef2977dd9d70e09581
Stats:     7 lines in 3 files changed: 5 ins; 1 del; 1 mod

8332014: since-checker - Fix @ since tags in jdk.jshell

Reviewed-by: jlahoda

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

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

From mbaesken at openjdk.org  Thu Jun 27 07:02:08 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 27 Jun 2024 07:02:08 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
In-Reply-To: <UkMJ-5GBtG0x4H3q5ZDL9SFNp67skwXZfG2bhPCq4qA=.5749d010-f9cd-4a54-8a8f-bc3c680a4c72@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <UkMJ-5GBtG0x4H3q5ZDL9SFNp67skwXZfG2bhPCq4qA=.5749d010-f9cd-4a54-8a8f-bc3c680a4c72@github.com>
Message-ID: <TVVJmbtpu_mTLIIDQRpFWEPgxKCPcazBcOwR0gYn2UQ=.cab53222-ab41-4a46-aec3-0cf2cb068ee3@github.com>

On Fri, 21 Jun 2024 15:04:11 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I put this PR into our build/test queues .

We did not see issues in our builds/test  (but jaikirans comment above needs to be considered of course).

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

PR Comment: https://git.openjdk.org/jdk/pull/19828#issuecomment-2193941936

From jlahoda at openjdk.org  Thu Jun 27 07:20:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 27 Jun 2024 07:20:10 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
In-Reply-To: <TVVJmbtpu_mTLIIDQRpFWEPgxKCPcazBcOwR0gYn2UQ=.cab53222-ab41-4a46-aec3-0cf2cb068ee3@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <UkMJ-5GBtG0x4H3q5ZDL9SFNp67skwXZfG2bhPCq4qA=.5749d010-f9cd-4a54-8a8f-bc3c680a4c72@github.com>
 <TVVJmbtpu_mTLIIDQRpFWEPgxKCPcazBcOwR0gYn2UQ=.cab53222-ab41-4a46-aec3-0cf2cb068ee3@github.com>
Message-ID: <pLEsXFQhW3mA6zZHrIuvoR-u1tEzuql-YXnVWi-eF4s=.6ff23b41-abcf-47c9-b17a-2d1927b545ff@github.com>

On Thu, 27 Jun 2024 06:59:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> I put this PR into our build/test queues .
>
>> I put this PR into our build/test queues .
> 
> We did not see issues in our builds/test  (but jaikirans comment above needs to be considered of course).

Thanks @MBaesken. I believe I've resolved Jaikiran's comments (maybe except the fact that the test is circular and calls itself - that is fairly widespread in the langtools tests). Jaikiran - please let me know if something is missing. It would be good to push this sometime soon, so that it gets some testing in the mainline, and can be backported into JDK 23 before RDP2. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/19828#issuecomment-2193969117

From jpai at openjdk.org  Thu Jun 27 07:34:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Jun 2024 07:34:09 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
 [v2]
In-Reply-To: <Gc2Rad_PTIBiNrP7iGcQM0b916OHKv_R7kK4DEScdT4=.85168d47-2c6c-490a-8757-f74a91d956e8@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <Gc2Rad_PTIBiNrP7iGcQM0b916OHKv_R7kK4DEScdT4=.85168d47-2c6c-490a-8757-f74a91d956e8@github.com>
Message-ID: <Vsd3FW-JRYGA6EMPCrO0Le4UkfWFEQXMWpfvxvH8gdQ=.32ad59f3-08f6-486a-87ec-6b89eb30e506@github.com>

On Tue, 25 Jun 2024 12:38:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
>> 
>> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
>> 
>> The proposal herein is twofold:
>> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
>> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
>> 
>> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
>> 
>> @MBaesken, please let me know what you think of this change.
>> 
>> I would like to backport this to JDK 23.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Hello Jan,

> Thanks @MBaesken. I believe I've resolved Jaikiran's comments (maybe except the fact that the test is circular and calls itself - that is fairly widespread in the langtools tests). Jaikiran - please let me know if something is missing.

The test changes look fine to me. I've approved the PR. I think the question Matthias noted was my previous comment about whether the paths hardcoded in the source changes would work fine on AIX and if there's some specific manual test(s) that Matthias can run to verify those paths are OK and doesn't affect any jshell functionality on AIX. If existing jtreg tests (other than the newly introduced jtreg test which won't run on AIX) cover the necessary use cases, that's good enough too.

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

PR Comment: https://git.openjdk.org/jdk/pull/19828#issuecomment-2193994529

From jlahoda at openjdk.org  Thu Jun 27 15:11:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 27 Jun 2024 15:11:10 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
 [v2]
In-Reply-To: <Gc2Rad_PTIBiNrP7iGcQM0b916OHKv_R7kK4DEScdT4=.85168d47-2c6c-490a-8757-f74a91d956e8@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <Gc2Rad_PTIBiNrP7iGcQM0b916OHKv_R7kK4DEScdT4=.85168d47-2c6c-490a-8757-f74a91d956e8@github.com>
Message-ID: <RM-LKEMTSLaGtXlNoXO83veYc4t5Yzj6afyQhVbcQ0U=.99ca733b-d847-4274-81a8-ef43ecdc6fd3@github.com>

On Tue, 25 Jun 2024 12:38:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
>> 
>> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
>> 
>> The proposal herein is twofold:
>> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
>> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
>> 
>> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
>> 
>> @MBaesken, please let me know what you think of this change.
>> 
>> I would like to backport this to JDK 23.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Thanks jaikiran for comments. Yes, a manual test would be welcome. But, I think this needs some baking time, and there's not much time left for JDK 23. I've got a clean tier1-3 build/test, so unless there are objections, I'll integrate tomorrow. Any further confirmation it works on AIX would still be welcome.

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

PR Comment: https://git.openjdk.org/jdk/pull/19828#issuecomment-2194973787

From jpai at openjdk.org  Thu Jun 27 15:26:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Jun 2024 15:26:11 GMT
Subject: RFR: 8334433: jshell.exe runs an executable test.exe on startup
 [v2]
In-Reply-To: <RM-LKEMTSLaGtXlNoXO83veYc4t5Yzj6afyQhVbcQ0U=.99ca733b-d847-4274-81a8-ef43ecdc6fd3@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
 <Gc2Rad_PTIBiNrP7iGcQM0b916OHKv_R7kK4DEScdT4=.85168d47-2c6c-490a-8757-f74a91d956e8@github.com>
 <RM-LKEMTSLaGtXlNoXO83veYc4t5Yzj6afyQhVbcQ0U=.99ca733b-d847-4274-81a8-ef43ecdc6fd3@github.com>
Message-ID: <v9uZ3x7rlDZdh1ufHuHDz0JU0mDZIGlXgeANhlmZRbw=.040ab547-8d27-4b3c-b6f5-9c4fe543235f@github.com>

On Thu, 27 Jun 2024 15:08:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> I've got a clean tier1-3 build/test, so unless there are objections, I'll integrate tomorrow.

That sounds good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/19828#issuecomment-2195009788

From jlahoda at openjdk.org  Fri Jun 28 09:34:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Jun 2024 09:34:27 GMT
Subject: Integrated: 8334433: jshell.exe runs an executable test.exe on startup
In-Reply-To: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
References: <lGvoE2LKioi6-Ot6pkPb_LN2nNN371D76UxJSGrybSc=.b3b69379-5cad-4aff-a7f1-3ab0dec09d60@github.com>
Message-ID: <oNBjGsGZJhDWoc5fjuSb07YlvS2ffjC4cpMUYO4q35g=.f12a127a-1ae8-4434-a6a7-44d1d0e4b485@github.com>

On Fri, 21 Jun 2024 13:45:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
> 
> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
> 
> The proposal herein is twofold:
> - disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
> - make the "exec" provider ignore the `PATH` environment variable, and use hardcoded value.
> 
> I tested this on Windows with `cmd`, Cygwin and MSYS, and on Linux and seemed to work fine.
> 
> @MBaesken, please let me know what you think of this change.
> 
> I would like to backport this to JDK 23.

This pull request has now been integrated.

Changeset: 99d2bbf7
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99d2bbf767ac33e1a021c90ba12d95ef37ea4816
Stats:     103 lines in 3 files changed: 101 ins; 0 del; 2 mod

8334433: jshell.exe runs an executable test.exe on startup

Reviewed-by: jpai

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

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

From jlahoda at openjdk.org  Fri Jun 28 12:25:51 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 28 Jun 2024 12:25:51 GMT
Subject: [jdk23] RFR: 8334433: jshell.exe runs an executable test.exe on
 startup
Message-ID: <S54wN4nWPdKLbmJi1vNlciNeBUCoRGwrmTgDIMgy_hE=.f4c0f69b-085a-40c9-9e11-05c3fc753a3e@github.com>

Hi all,

This pull request contains a backport of commit [99d2bbf7](https://github.com/openjdk/jdk/commit/99d2bbf767ac33e1a021c90ba12d95ef37ea4816) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jan Lahoda on 28 Jun 2024 and was reviewed by Jaikiran Pai.

Thanks!

Original description:
JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.

We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.

The proposal herein is twofold:

 -    disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
 -    make the "exec" provider ignore the PATH environment variable, and use hardcoded value.

I tested this on Windows with cmd, Cygwin and MSYS, and on Linux and seemed to work fine.

@MBaesken, please let me know what you think of this change.

I would like to backport this to JDK 23.

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

Commit messages:
 - Backport 99d2bbf767ac33e1a021c90ba12d95ef37ea4816

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

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

From liach at openjdk.org  Fri Jun 28 22:06:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Jun 2024 22:06:41 GMT
Subject: RFR: 8335290: Rename ClassFile::transform to ClassFile::transformClass
Message-ID: <5NG5xsfGLEgvpDSJSGtBTOtkkgypIE7UkWTNuUHO3wE=.5bd451ba-398e-4649-8e46-8d87a7f6d91e@github.com>

`ClassFile::transform` was initially `ClassModel::transform`, which transforms the receiver class model to a new class byte array. This functionality was in parallel with `ClassBuilder::transform`, which accepts a `ClassModel` and a `ClassTransform` and forwards the results to the receiver builder.

After the `ClassFile` context object introduction, `ClassModel::transform` becomes `ClassFile::transform`; now, its role is more similar to `ClassBuilder::transformMethod`, `ClassBuilder::transformField`, or `MethodBuilder::transformCode` (transforming subtypes), and it is confusing with `ClassFileBuilder::transform` (which accepts the same model type as the built type). We should rename `ClassFile::transform` to `ClassFile::transformClass` to make this method's role more clear.

This is separate from #19928 as this has much more user impact.

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

Commit messages:
 - Doc typo
 - Missed 3 files
 - ClassFile.transform -> transformClass

Changes: https://git.openjdk.org/jdk/pull/19952/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335290
  Stats: 177 lines in 58 files changed: 2 ins; 5 del; 170 mod
  Patch: https://git.openjdk.org/jdk/pull/19952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19952/head:pull/19952

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

From vromero at openjdk.org  Fri Jun 28 22:14:28 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 28 Jun 2024 22:14:28 GMT
Subject: [jdk23] RFR: 8334433: jshell.exe runs an executable test.exe on
 startup
In-Reply-To: <S54wN4nWPdKLbmJi1vNlciNeBUCoRGwrmTgDIMgy_hE=.f4c0f69b-085a-40c9-9e11-05c3fc753a3e@github.com>
References: <S54wN4nWPdKLbmJi1vNlciNeBUCoRGwrmTgDIMgy_hE=.f4c0f69b-085a-40c9-9e11-05c3fc753a3e@github.com>
Message-ID: <hW3_bY7FOxznXyEOxvFx3eadEm97L3OvVRkKJ-VLhB4=.6c95045f-57a4-4ecc-ab16-f554fc37202c@github.com>

On Fri, 28 Jun 2024 12:20:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [99d2bbf7](https://github.com/openjdk/jdk/commit/99d2bbf767ac33e1a021c90ba12d95ef37ea4816) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jan Lahoda on 28 Jun 2024 and was reviewed by Jaikiran Pai.
> 
> Thanks!
> 
> Original description:
> JLine has multiple providers that can setup and work with the native terminals. As part of an upgrade to JLine 3.26.1 (https://github.com/openjdk/jdk/pull/18142), a first phase of checks in the terminal providers providers runs fairly soon, when the providers are gathered. There is also a provider which setups the terminals using command line utilities - the "exec" provider. And this provider currently runs the "test" command line utility during the gathering phase, which (I believe) was not the case in previous version. I.e. even if some other provider is used to work with the terminal, the "exec" terminal might run the "test" utility anyway.
> 
> We currently largely don't need the "exec" provider at all - we currently primarily use a semi-native provider based on FFM. The "exec" provider is, I believe, used on platforms for which the FFM provider is not implemented, which is probably primarily AIX.
> 
> The proposal herein is twofold:
> 
>  -    disable the "exec" terminal on platforms for the FFM provider should work (Windows, Linux, Mac)
>  -    make the "exec" provider ignore the PATH environment variable, and use hardcoded value.
> 
> I tested this on Windows with cmd, Cygwin and MSYS, and on Linux and seemed to work fine.
> 
> @MBaesken, please let me know what you think of this change.
> 
> I would like to backport this to JDK 23.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19939#pullrequestreview-2149059456