From vyazici at openjdk.org  Mon Jun  2 11:25:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 11:25:30 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [build/tools] [v2]
In-Reply-To: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
Message-ID: <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to build and tools.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Provide fallback for `stdin.encoding` in `ExternalEditor`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25541/files
  - new: https://git.openjdk.org/jdk/pull/25541/files/329180f5..c0dfa806

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

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

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

From vyazici at openjdk.org  Mon Jun  2 11:25:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 11:25:31 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [build/tools] [v2]
In-Reply-To: <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
 <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com>
Message-ID: <MFFrjyTzk_ej3pJCwlYbpbfEta6CSHn4X2mMdiLawYs=.dbf3d8d3-b485-4e4c-9ceb-4e6a7c23f10c@github.com>

On Mon, 2 Jun 2025 11:22:21 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to build and tools.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding` in `ExternalEditor`

src/utils/src/build/tools/commentchecker/CommentChecker.java line 197:

> 195:             try {
> 196:                 BufferedReader br =
> 197:                     new BufferedReader(new InputStreamReader(System.in, System.getProperty("stdin.encoding")));

Not providing a `Charset` fallback ? `CommentChecker` build tool should better fail if an invalid `stdin.encoding` is configured.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25541#discussion_r2120845904

From davidalayachew at gmail.com  Tue Jun  3 00:52:54 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 2 Jun 2025 20:52:54 -0400
Subject: jshell has unreadable javadoc on Git Bash
Message-ID: <CAA9v-_OUknzCp0KsytMfT51jAJYswWOPDT2-N_W_N12gTYuMDg@mail.gmail.com>

Hello @kulla-dev at openjdk.org <kulla-dev at openjdk.org> ,

I was using jshell to write some stream code today, and I was doing this in
Git Bash on Windows 10.

I did list.stream(), then used Shift+Enter to create a new line for each
method on my stream. Typical builder-style code formatting.

Then, I pressed Tab in order to see javadoc for one of the methods, and the
resulting javadoc was basically illegible. It was a mix of the multi-line
stream and the javadoc, jumbled together.

I think this is a bug? Can something be done to resolve this? Let me know
if more information is needed.

Thank you for your time and consideration.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250602/64e68a2f/attachment.htm>

From davidalayachew at gmail.com  Tue Jun  3 00:57:43 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 2 Jun 2025 20:57:43 -0400
Subject: jshell has unreadable javadoc on Git Bash
In-Reply-To: <CAA9v-_OUknzCp0KsytMfT51jAJYswWOPDT2-N_W_N12gTYuMDg@mail.gmail.com>
References: <CAA9v-_OUknzCp0KsytMfT51jAJYswWOPDT2-N_W_N12gTYuMDg@mail.gmail.com>
Message-ID: <CAA9v-_OABhfYKb2j+CQAbhFUXgUx=W0j_pN+U9f7=1sEnQ3pVA@mail.gmail.com>

Side note -- the same problem occurs in Commandline too for Windows 10. The
only difference is that I can't use Shift+Enter to create the new lines.
Instead, I did a .map(somePath -> {, and then pressed enter. The opening
curly brace then allowed my enter to create a new line. After making a few
new lines, then trying to press tab on a half-typed method, I got the same,
garbled text.


And to be clear, they are garbled/interspersed, even on the same line.

On Mon, Jun 2, 2025, 8:52?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello @kulla-dev at openjdk.org <kulla-dev at openjdk.org> ,
>
> I was using jshell to write some stream code today, and I was doing this
> in Git Bash on Windows 10.
>
> I did list.stream(), then used Shift+Enter to create a new line for each
> method on my stream. Typical builder-style code formatting.
>
> Then, I pressed Tab in order to see javadoc for one of the methods, and
> the resulting javadoc was basically illegible. It was a mix of the
> multi-line stream and the javadoc, jumbled together.
>
> I think this is a bug? Can something be done to resolve this? Let me know
> if more information is needed.
>
> Thank you for your time and consideration.
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250602/6ddf711d/attachment-0001.htm>

From nbenalla at openjdk.org  Tue Jun  3 11:19:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:19:34 GMT
Subject: RFR: 8346884: Add since checker test to jdk.editpad
Message-ID: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>

Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module.

TIA

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

Commit messages:
 - add new `@since` test

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

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

From nbenalla at openjdk.org  Tue Jun  3 11:19:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 3 Jun 2025 11:19:34 GMT
Subject: RFR: 8346884: Add since checker test to jdk.editpad
In-Reply-To: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
References: <eqA9zD_EnXUJr7Q_xq7OZbBzAxViuUHyzy0Tw6LtZ8U=.6868ebd9-4afa-4a03-8c2d-7addef9a2ddf@github.com>
Message-ID: <CKteKl44uoBG40c95jLiAemwvEUmI-3X9nrJOfz8Q4s=.a0e6aefa-ef23-4746-9174-5eeb0ab25b99@github.com>

On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to add a new test to check `@since` tags in the `jdk.editpad` module.
> 
> TIA

I realize there are no classfiles in `jdk.editpad` but the test can also check the `@since` information in the `module-info.java` file.

The goal is to have an `@since` test per module.

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

PR Comment: https://git.openjdk.org/jdk/pull/25613#issuecomment-2934750409

From ihse at openjdk.org  Tue Jun  3 19:20:20 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 19:20:20 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [build/tools] [v2]
In-Reply-To: <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
 <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com>
Message-ID: <VE6-ysfybzJbgR-ScS5S3G3Z_k7_4nfolGr8Yp_aQDM=.e4064ea2-50b8-4e83-b3fc-b68e1faa58d1@github.com>

On Mon, 2 Jun 2025 11:25:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to build and tools.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Provide fallback for `stdin.encoding` in `ExternalEditor`

Maybe you should update the JBS title?

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

PR Comment: https://git.openjdk.org/jdk/pull/25541#issuecomment-2936822614

From vyazici at openjdk.org  Tue Jun  3 19:39:22 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 3 Jun 2025 19:39:22 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [tools] [v2]
In-Reply-To: <VE6-ysfybzJbgR-ScS5S3G3Z_k7_4nfolGr8Yp_aQDM=.e4064ea2-50b8-4e83-b3fc-b68e1faa58d1@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
 <1QWJ_Ube42oc8fNmEnCWJb3J5HNR2aaDhbxW2NwT6MA=.4da44e83-fe48-43a8-8537-925135166c04@github.com>
 <VE6-ysfybzJbgR-ScS5S3G3Z_k7_4nfolGr8Yp_aQDM=.e4064ea2-50b8-4e83-b3fc-b68e1faa58d1@github.com>
Message-ID: <qcwzQNhPR1XDKFgcKxTgfR2kmmkxhieo9KiLitxn_F8=.f4e9cab1-f58c-489f-b12b-041ea4e2e5a4@github.com>

On Tue, 3 Jun 2025 19:17:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Maybe you should update the JBS title?

@magicus, removed the mention of `build` from

- JBS title
- JBS description
- PR title
- PR description

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

PR Comment: https://git.openjdk.org/jdk/pull/25541#issuecomment-2936882813

From rgiulietti at openjdk.org  Thu Jun  5 09:36:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Jun 2025 09:36:54 GMT
Subject: RFR: 8356633: Incorrect use of {@link} in jdk.jshell
In-Reply-To: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>
References: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>
Message-ID: <LFIKgSUDLHa0WbF7Lyr7ohsfmyUEhNiGztNcGDz3W48=.34cb9610-f997-4b61-885f-5853515c8e47@github.com>

On Sat, 17 May 2025 16:41:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some javadoc bugs.
> 
> TIA

LGTM

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25285#pullrequestreview-2899578003

From vyazici at openjdk.org  Thu Jun  5 10:05:49 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 10:05:49 GMT
Subject: RFR: 8356633: Incorrect use of {@link} in jdk.jshell
In-Reply-To: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>
References: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>
Message-ID: <71IJZsx-it0VdCd-NEpjwRzR0oft_8_e7DfsgGaYexU=.15a2f57f-09c9-46a9-8024-103c563e0893@github.com>

On Sat, 17 May 2025 16:41:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some javadoc bugs.
> 
> TIA

Marked as reviewed by vyazici (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/25285#pullrequestreview-2899682449

From nbenalla at openjdk.org  Thu Jun  5 10:35:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 5 Jun 2025 10:35:57 GMT
Subject: RFR: 8356633: Incorrect use of {@link} in jdk.jshell
In-Reply-To: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>
References: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>
Message-ID: <0NNDVnx1iTD1C-LvawfhwHm-6JzvEcnG-GPDcRerixs=.392db175-f8a1-4b89-a7b2-558c63b53457@github.com>

On Sat, 17 May 2025 16:41:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some javadoc bugs.
> 
> TIA

Thanks for the reviews. Integrating this now before RDP1.

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

PR Comment: https://git.openjdk.org/jdk/pull/25285#issuecomment-2943645924

From nbenalla at openjdk.org  Thu Jun  5 10:35:57 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 5 Jun 2025 10:35:57 GMT
Subject: Integrated: 8356633: Incorrect use of {@link} in jdk.jshell
In-Reply-To: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>
References: <viguYQid2pKcE_luFjZeBEGXG6Mr2adwORq9S9cQXkY=.d5f9ed82-6299-4291-9537-5113a3cdc6d2@github.com>
Message-ID: <M6ZdNYAkRKutB5iuIYTbUWXAVY2U6SbGzQgqOS930to=.9a340824-280d-4d02-8f68-70d44aa8777d@github.com>

On Sat, 17 May 2025 16:41:07 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to fix some javadoc bugs.
> 
> TIA

This pull request has now been integrated.

Changeset: bd08932d
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd08932d5b9d1a363d8229ea72df4c6dbfd4571d
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8356633: Incorrect use of {@link} in jdk.jshell

Reviewed-by: rgiulietti, vyazici

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

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

From vyazici at openjdk.org  Fri Jun  6 07:08:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:08:28 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [tools] [v3]
In-Reply-To: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
Message-ID: <LvPc9fPyljo0rGQszM6Ha5wsgQmFEdZc0Th9rjPJbio=.2ed3a2f1-554b-4e01-8edf-bd2971c69b48@github.com>

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to tools.

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge remote-tracking branch 'upstream/master' into stdinEnc-build
 - Provide fallback for `stdin.encoding` in `ExternalEditor`
 - Discard changes unrelated with build and tools
 - Revert superfluous changes
   
   Remove assertion in `DOMImplementationRegistry`
 - Revert changes to 3rd parties in `com/sun/org/apache`
 - Revert `PandocFilter` changes
   
   `PandocFilter` et al. gets called using the boot JDK,
   which doesn't have `stdin.encoding` yet.
 - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations
   
   Improve `CharsetTest`

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

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

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

From acobbs at openjdk.org  Tue Jun 10 14:29:07 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Jun 2025 14:29:07 GMT
Subject: RFR: 8359131: JShell AbstractStopExecutionTest does not stop reliably
Message-ID: <GQpTrNtvQk4osOGf2jag4o3cFzveGNUsM8qb8o05zlQ=.acb3964b-1f4b-4e19-90a3-2529ea079902@github.com>

The JShell regression test support class `AbstractStopExecutionTest.java` provides code that starts a JShell evaluation in one thread and then invokes `JShell.stop()` to interrupt that evaluation from another thread.

This class uses a `boolean` field to synchronize the action between threads. However, this field is not marked `volatile` and so the communication is unreliable. As a result, in rare cases, the test can fail due to a timeout.

The simple fix is to make the field `volatile`. This has been verified in testing to resolve the problem (see discussion in [JDK-8355323](https://bugs.openjdk.org/browse/JDK-8355323)).

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

Commit messages:
 - Mark racy field volatile.

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

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

From shade at openjdk.org  Tue Jun 10 16:07:34 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 10 Jun 2025 16:07:34 GMT
Subject: RFR: 8359131: JShell AbstractStopExecutionTest does not stop
 reliably
In-Reply-To: <GQpTrNtvQk4osOGf2jag4o3cFzveGNUsM8qb8o05zlQ=.acb3964b-1f4b-4e19-90a3-2529ea079902@github.com>
References: <GQpTrNtvQk4osOGf2jag4o3cFzveGNUsM8qb8o05zlQ=.acb3964b-1f4b-4e19-90a3-2529ea079902@github.com>
Message-ID: <PkY2MytY4PBk68M8B7d-gataXacZG5AZPxtWnkF22yo=.43ef95cf-6742-48e8-9949-ca50fd7b1165@github.com>

On Tue, 10 Jun 2025 14:24:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The JShell regression test support class `AbstractStopExecutionTest.java` provides code that starts a JShell evaluation in one thread and then invokes `JShell.stop()` to interrupt that evaluation from another thread.
> 
> This class uses a `boolean` field to synchronize the action between threads. However, this field is not marked `volatile` and so the communication is unreliable. As a result, in rare cases, the test can fail due to a timeout.
> 
> The simple fix is to make the field `volatile`. This has been verified in testing to resolve the problem (see discussion in [JDK-8355323](https://bugs.openjdk.org/browse/JDK-8355323)).

Really confusing how `volatile` helps here. There are three accesses to `isStopped`:
 1. `isStopped = false;` initially in this thread
 2. `isStopped` checks in separate threads.
 3. `isStopped = true;` in this thread

(2) and (3) are done under `synchronized(lock)`. `Thread.start` synchronizes-with the `Thread.run`, so passing `false` (1) to separate threads (2) should work. These two should be enough to maintain correctness.

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

PR Review: https://git.openjdk.org/jdk/pull/25730#pullrequestreview-2914242450

From acobbs at openjdk.org  Tue Jun 10 16:18:28 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Jun 2025 16:18:28 GMT
Subject: RFR: 8359131: JShell AbstractStopExecutionTest does not stop
 reliably
In-Reply-To: <PkY2MytY4PBk68M8B7d-gataXacZG5AZPxtWnkF22yo=.43ef95cf-6742-48e8-9949-ca50fd7b1165@github.com>
References: <GQpTrNtvQk4osOGf2jag4o3cFzveGNUsM8qb8o05zlQ=.acb3964b-1f4b-4e19-90a3-2529ea079902@github.com>
 <PkY2MytY4PBk68M8B7d-gataXacZG5AZPxtWnkF22yo=.43ef95cf-6742-48e8-9949-ca50fd7b1165@github.com>
Message-ID: <wMK_XVKAzFBsMAbG9vZ5pCBj-2jes67R-GGFvRb_j4U=.fc8dff3b-b709-431e-8426-631fc09d28a7@github.com>

On Tue, 10 Jun 2025 16:05:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Really confusing how `volatile` helps here.

Yep, I agree with you - I misread the synchronization logic before, thinking there was a race.

So maybe this "fix" is just a red herring, which means the real problem remains unknown.

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

PR Comment: https://git.openjdk.org/jdk/pull/25730#issuecomment-2959892641

From acobbs at openjdk.org  Tue Jun 10 18:33:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Jun 2025 18:33:33 GMT
Subject: RFR: 8359131: JShell AbstractStopExecutionTest does not stop
 reliably
In-Reply-To: <GQpTrNtvQk4osOGf2jag4o3cFzveGNUsM8qb8o05zlQ=.acb3964b-1f4b-4e19-90a3-2529ea079902@github.com>
References: <GQpTrNtvQk4osOGf2jag4o3cFzveGNUsM8qb8o05zlQ=.acb3964b-1f4b-4e19-90a3-2529ea079902@github.com>
Message-ID: <K_U51e0-p5xf52PRsxhUmz_DYR9B62tvv4353ba6iXk=.34fe1dab-4657-4f74-b30f-58af870cc643@github.com>

On Tue, 10 Jun 2025 14:24:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The JShell regression test support class `AbstractStopExecutionTest.java` provides code that starts a JShell evaluation in one thread and then invokes `JShell.stop()` to interrupt that evaluation from another thread.
> 
> This class uses a `boolean` field to synchronize the action between threads. However, this field is not marked `volatile` and so the communication is unreliable. As a result, in rare cases, the test can fail due to a timeout.
> 
> The simple fix is to make the field `volatile`. This has been verified in testing to resolve the problem (see discussion in [JDK-8355323](https://bugs.openjdk.org/browse/JDK-8355323)).

Closing this PR since the fix doesn't make sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/25730#issuecomment-2960239559

From acobbs at openjdk.org  Tue Jun 10 18:33:33 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Jun 2025 18:33:33 GMT
Subject: Withdrawn: 8359131: JShell AbstractStopExecutionTest does not stop
 reliably
In-Reply-To: <GQpTrNtvQk4osOGf2jag4o3cFzveGNUsM8qb8o05zlQ=.acb3964b-1f4b-4e19-90a3-2529ea079902@github.com>
References: <GQpTrNtvQk4osOGf2jag4o3cFzveGNUsM8qb8o05zlQ=.acb3964b-1f4b-4e19-90a3-2529ea079902@github.com>
Message-ID: <jh266YkjWzqMkofEs5e-x_KO287ShcX9g93suRPLTIE=.794de7d5-c4c1-4870-bf51-1f7008ff3770@github.com>

On Tue, 10 Jun 2025 14:24:15 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The JShell regression test support class `AbstractStopExecutionTest.java` provides code that starts a JShell evaluation in one thread and then invokes `JShell.stop()` to interrupt that evaluation from another thread.
> 
> This class uses a `boolean` field to synchronize the action between threads. However, this field is not marked `volatile` and so the communication is unreliable. As a result, in rare cases, the test can fail due to a timeout.
> 
> The simple fix is to make the field `volatile`. This has been verified in testing to resolve the problem (see discussion in [JDK-8355323](https://bugs.openjdk.org/browse/JDK-8355323)).

This pull request has been closed without being integrated.

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

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

From volkan at yazi.ci  Wed Jun 11 12:39:09 2025
From: volkan at yazi.ci (=?UTF-8?B?Vm9sa2FuIFlhesSxY8Sx?=)
Date: Wed, 11 Jun 2025 14:39:09 +0200
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [tools]
Message-ID: <CABDM8gBAGF=_2KVmWeBmjA+pW80mceJBsC8P-R9xV_BrDE-j5g@mail.gmail.com>

Hello,

#25541 <https://github.com/openjdk/jdk/pull/25541> implements relatively
simple changes in following files to use `stdin.encoding` for reading
`System.in` with `InputStreamReader`/`Scanner`:

src/jdk.internal.ed/share/classes/jdk/internal/editor/external/ExternalEditor.java
test/langtools/jdk/jshell/CompletenessTest.java
test/langtools/jdk/jshell/UserInputTest.java

I'd appreciate it if somebody could review these changes.

Kind regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250611/4908812a/attachment.htm>

From sven.reimers at gmail.com  Thu Jun 12 18:39:00 2025
From: sven.reimers at gmail.com (Sven Reimers)
Date: Thu, 12 Jun 2025 20:39:00 +0200
Subject: IllegalArgumentException in highlights
Message-ID: <CAP+Jvx7FJze=N7fam4-U8JsfArgYkY_rHbj3Dy7e_RyjK=+NEg@mail.gmail.com>

Hi,

working on highlighting in JTaccuino I found

Caused by: java.lang.IllegalArgumentException
at
jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:647)
at
jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:627)
at
jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.create(JCDiagnostic.java:301)
at
jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.error(JCDiagnostic.java:114)
at
jdk.compiler/com.sun.tools.javac.util.AbstractLog.error(AbstractLog.java:145)
at
jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.lexError(JavaTokenizer.java:202)
at
jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.scanString(JavaTokenizer.java:468)
at
jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.readToken(JavaTokenizer.java:1015)
at
jdk.compiler/com.sun.tools.javac.parser.Scanner.nextToken(Scanner.java:124)
at
jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.lambda$highlights$0(SourceCodeAnalysisImpl.java:647)
at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$1(TaskFactory.java:218)
at
jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:211)
at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:180)
at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:166)
at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:155)
at
jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.highlights(SourceCodeAnalysisImpl.java:618)

happening, when a snippet is sent with a not closed quoted string, e.g.

System.out.println("

I assume this should not happen?

Thanks

Sven

-- 
Sven Reimers

* Java Champion
* Apache NetBeans PMC: http://netbeans.apache.org
* JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250612/1e64717c/attachment-0001.htm>

From archie.cobbs at gmail.com  Thu Jun 12 18:56:37 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 12 Jun 2025 13:56:37 -0500
Subject: IllegalArgumentException in highlights
In-Reply-To: <CAP+Jvx7FJze=N7fam4-U8JsfArgYkY_rHbj3Dy7e_RyjK=+NEg@mail.gmail.com>
References: <CAP+Jvx7FJze=N7fam4-U8JsfArgYkY_rHbj3Dy7e_RyjK=+NEg@mail.gmail.com>
Message-ID: <CANSoFxvkqMg_Ls_kHJ8wG4ZnS-Kfkfp8S+WZaQFU101ZaOr+VA@mail.gmail.com>

What JDK version?

On Thu, Jun 12, 2025 at 1:39?PM Sven Reimers <sven.reimers at gmail.com> wrote:

> Hi,
>
> working on highlighting in JTaccuino I found
>
> Caused by: java.lang.IllegalArgumentException
> at
> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:647)
> at
> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:627)
> at
> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.create(JCDiagnostic.java:301)
> at
> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.error(JCDiagnostic.java:114)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractLog.error(AbstractLog.java:145)
> at
> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.lexError(JavaTokenizer.java:202)
> at
> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.scanString(JavaTokenizer.java:468)
> at
> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.readToken(JavaTokenizer.java:1015)
> at
> jdk.compiler/com.sun.tools.javac.parser.Scanner.nextToken(Scanner.java:124)
> at
> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.lambda$highlights$0(SourceCodeAnalysisImpl.java:647)
> at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$1(TaskFactory.java:218)
> at
> jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
> at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:211)
> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:180)
> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:166)
> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:155)
> at
> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.highlights(SourceCodeAnalysisImpl.java:618)
>
> happening, when a snippet is sent with a not closed quoted string, e.g.
>
> System.out.println("
>
> I assume this should not happen?
>
> Thanks
>
> Sven
>
> --
> Sven Reimers
>
> * Java Champion
> * Apache NetBeans PMC: http://netbeans.apache.org
> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250612/9ab6869b/attachment.htm>

From naoto at openjdk.org  Thu Jun 12 19:18:33 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 19:18:33 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [tools] [v3]
In-Reply-To: <LvPc9fPyljo0rGQszM6Ha5wsgQmFEdZc0Th9rjPJbio=.2ed3a2f1-554b-4e01-8edf-bd2971c69b48@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
 <LvPc9fPyljo0rGQszM6Ha5wsgQmFEdZc0Th9rjPJbio=.2ed3a2f1-554b-4e01-8edf-bd2971c69b48@github.com>
Message-ID: <Dm6kf11nuhM_xBSyWFsQ0RGNg3MR3WQ1SP-YwnM8q9s=.23670e5a-5140-4ac2-930a-e18c0ea550dd@github.com>

On Fri, 6 Jun 2025 07:08:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to tools.
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into stdinEnc-build
>  - Provide fallback for `stdin.encoding` in `ExternalEditor`
>  - Discard changes unrelated with build and tools
>  - Revert superfluous changes
>    
>    Remove assertion in `DOMImplementationRegistry`
>  - Revert changes to 3rd parties in `com/sun/org/apache`
>  - Revert `PandocFilter` changes
>    
>    `PandocFilter` et al. gets called using the boot JDK,
>    which doesn't have `stdin.encoding` yet.
>  - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations
>    
>    Improve `CharsetTest`

src/jdk.internal.ed/share/classes/jdk/internal/editor/external/ExternalEditor.java line 170:

> 168:                 // -wait option -- ignore process exit, wait for carriage-return
> 169:                 Charset charset = Charset.forName(System.getProperty("stdin.encoding"), Charset.defaultCharset());
> 170:                 Scanner scanner = new Scanner(System.in, charset);

I think the code is simply expecting a CR, so this change may not be needed.

test/langtools/jdk/jshell/CompletenessTest.java line 103:

> 101:         "final Deque<Token> stack = new ArrayDeque<>()",
> 102:         "java.util.Scanner input = new java.util.Scanner(System.in, System.getProperty(\"stdin.encoding\"))",
> 103:         "java.util.Scanner input = new java.util.Scanner(System.in, System.getProperty(\"stdin.encoding\")) { }",

These seem to be checking a unit is complete or not, so these changes may be irrelevant too.

test/langtools/jdk/jshell/UserInputTest.java line 50:

> 48:     public void testScanner() {
> 49:         assertEval("import java.util.Scanner;");
> 50:         assertEval("Scanner s = new Scanner(System.in, System.getProperty(\"stdin.encoding\"));");

JShell's `System.in` is not a real `System.in` (set by `JShell.builder().in()`), so I think this one is not necessary either

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25541#discussion_r2143422630
PR Review Comment: https://git.openjdk.org/jdk/pull/25541#discussion_r2143427913
PR Review Comment: https://git.openjdk.org/jdk/pull/25541#discussion_r2143447300

From sven.reimers at gmail.com  Thu Jun 12 19:19:25 2025
From: sven.reimers at gmail.com (Sven Reimers)
Date: Thu, 12 Jun 2025 21:19:25 +0200
Subject: IllegalArgumentException in highlights
In-Reply-To: <CANSoFxvkqMg_Ls_kHJ8wG4ZnS-Kfkfp8S+WZaQFU101ZaOr+VA@mail.gmail.com>
References: <CAP+Jvx7FJze=N7fam4-U8JsfArgYkY_rHbj3Dy7e_RyjK=+NEg@mail.gmail.com>
 <CANSoFxvkqMg_Ls_kHJ8wG4ZnS-Kfkfp8S+WZaQFU101ZaOr+VA@mail.gmail.com>
Message-ID: <CAP+Jvx7W1Hk92dqPoHc832dhzHRYm-HY_rx_yxeVwi598-k1qA@mail.gmail.com>

JDK 24

Sven

On Thu, Jun 12, 2025 at 8:56?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> What JDK version?
>
> On Thu, Jun 12, 2025 at 1:39?PM Sven Reimers <sven.reimers at gmail.com>
> wrote:
>
>> Hi,
>>
>> working on highlighting in JTaccuino I found
>>
>> Caused by: java.lang.IllegalArgumentException
>> at
>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:647)
>> at
>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:627)
>> at
>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.create(JCDiagnostic.java:301)
>> at
>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.error(JCDiagnostic.java:114)
>> at
>> jdk.compiler/com.sun.tools.javac.util.AbstractLog.error(AbstractLog.java:145)
>> at
>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.lexError(JavaTokenizer.java:202)
>> at
>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.scanString(JavaTokenizer.java:468)
>> at
>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.readToken(JavaTokenizer.java:1015)
>> at
>> jdk.compiler/com.sun.tools.javac.parser.Scanner.nextToken(Scanner.java:124)
>> at
>> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.lambda$highlights$0(SourceCodeAnalysisImpl.java:647)
>> at
>> jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$1(TaskFactory.java:218)
>> at
>> jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>> at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:211)
>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:180)
>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:166)
>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:155)
>> at
>> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.highlights(SourceCodeAnalysisImpl.java:618)
>>
>> happening, when a snippet is sent with a not closed quoted string, e.g.
>>
>> System.out.println("
>>
>> I assume this should not happen?
>>
>> Thanks
>>
>> Sven
>>
>> --
>> Sven Reimers
>>
>> * Java Champion
>> * Apache NetBeans PMC: http://netbeans.apache.org
>> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
>>
>
>
> --
> Archie L. Cobbs
>


-- 
Sven Reimers

* Java Champion
* Apache NetBeans PMC: http://netbeans.apache.org
* JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
* Duke's Choice Award Winner 2009 & 2018

* LinkedIn: http://www.linkedin.com/in/svenreimers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250612/68a9f6d5/attachment-0001.htm>

From vyazici at openjdk.org  Fri Jun 13 06:44:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 06:44:44 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [tools] [v3]
In-Reply-To: <LvPc9fPyljo0rGQszM6Ha5wsgQmFEdZc0Th9rjPJbio=.2ed3a2f1-554b-4e01-8edf-bd2971c69b48@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
 <LvPc9fPyljo0rGQszM6Ha5wsgQmFEdZc0Th9rjPJbio=.2ed3a2f1-554b-4e01-8edf-bd2971c69b48@github.com>
Message-ID: <C-rfd2rZufhPTSVaaTA00dozgkJ7uVX1uFbNPYrsljU=.71d4ddb7-6bce-4cff-abc5-a54783134b30@github.com>

On Fri, 6 Jun 2025 07:08:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
>> 
>> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to tools.
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into stdinEnc-build
>  - Provide fallback for `stdin.encoding` in `ExternalEditor`
>  - Discard changes unrelated with build and tools
>  - Revert superfluous changes
>    
>    Remove assertion in `DOMImplementationRegistry`
>  - Revert changes to 3rd parties in `com/sun/org/apache`
>  - Revert `PandocFilter` changes
>    
>    `PandocFilter` et al. gets called using the boot JDK,
>    which doesn't have `stdin.encoding` yet.
>  - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations
>    
>    Improve `CharsetTest`

@naotoj, thanks so much for taking time to review the changes. Your recent remarks explain why the current set of changes are superfluous ? closing the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25541#issuecomment-2969245930

From vyazici at openjdk.org  Fri Jun 13 06:44:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 06:44:45 GMT
Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [tools] [v3]
In-Reply-To: <Dm6kf11nuhM_xBSyWFsQ0RGNg3MR3WQ1SP-YwnM8q9s=.23670e5a-5140-4ac2-930a-e18c0ea550dd@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
 <LvPc9fPyljo0rGQszM6Ha5wsgQmFEdZc0Th9rjPJbio=.2ed3a2f1-554b-4e01-8edf-bd2971c69b48@github.com>
 <Dm6kf11nuhM_xBSyWFsQ0RGNg3MR3WQ1SP-YwnM8q9s=.23670e5a-5140-4ac2-930a-e18c0ea550dd@github.com>
Message-ID: <3z3L-bt9lMmGjtl2n487XiVhydXkq4wSzrQbRbM2fRg=.cf923d35-965a-40d4-accc-fcc76e5d7979@github.com>

On Thu, 12 Jun 2025 18:58:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into stdinEnc-build
>>  - Provide fallback for `stdin.encoding` in `ExternalEditor`
>>  - Discard changes unrelated with build and tools
>>  - Revert superfluous changes
>>    
>>    Remove assertion in `DOMImplementationRegistry`
>>  - Revert changes to 3rd parties in `com/sun/org/apache`
>>  - Revert `PandocFilter` changes
>>    
>>    `PandocFilter` et al. gets called using the boot JDK,
>>    which doesn't have `stdin.encoding` yet.
>>  - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations
>>    
>>    Improve `CharsetTest`
>
> src/jdk.internal.ed/share/classes/jdk/internal/editor/external/ExternalEditor.java line 170:
> 
>> 168:                 // -wait option -- ignore process exit, wait for carriage-return
>> 169:                 Charset charset = Charset.forName(System.getProperty("stdin.encoding"), Charset.defaultCharset());
>> 170:                 Scanner scanner = new Scanner(System.in, charset);
> 
> I think the code is simply expecting a CR, so this change may not be needed.

Correct. I could not be sure if CR is always the same across all charsets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25541#discussion_r2144311307

From vyazici at openjdk.org  Fri Jun 13 06:44:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 13 Jun 2025 06:44:46 GMT
Subject: Withdrawn: 8357996: Use "stdin.encoding" for reading System.in with
 InputStreamReader/Scanner [tools]
In-Reply-To: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
References: <uYEjhyAWjyat_rQLDhluHk94UFnqQroygDPyKUC5ixw=.dc57140a-6176-4a4e-b4d2-ee00419a24d6@github.com>
Message-ID: <U4WZqr2dRUlk_Qv5ix9_-b6Jb9CvB43rR0K7iXr7ymE=.7dc0d332-359d-40cc-9d46-d42c1c830d9b@github.com>

On Fri, 30 May 2025 10:46:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`.
> 
> `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to tools.

This pull request has been closed without being integrated.

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

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

From volkan at yazi.ci  Fri Jun 13 07:20:52 2025
From: volkan at yazi.ci (=?UTF-8?B?Vm9sa2FuIFlhesSxY8Sx?=)
Date: Fri, 13 Jun 2025 09:20:52 +0200
Subject: IllegalArgumentException in highlights
In-Reply-To: <CAP+Jvx7W1Hk92dqPoHc832dhzHRYm-HY_rx_yxeVwi598-k1qA@mail.gmail.com>
References: <CAP+Jvx7FJze=N7fam4-U8JsfArgYkY_rHbj3Dy7e_RyjK=+NEg@mail.gmail.com>
 <CANSoFxvkqMg_Ls_kHJ8wG4ZnS-Kfkfp8S+WZaQFU101ZaOr+VA@mail.gmail.com>
 <CAP+Jvx7W1Hk92dqPoHc832dhzHRYm-HY_rx_yxeVwi598-k1qA@mail.gmail.com>
Message-ID: <CABDM8gBtvnZQMN7g6V02xd48j1oXi35wPFST1_Bzp08-2q53Ug@mail.gmail.com>

Downloaded JDK 24.0.1
<https://www.oracle.com/java/technologies/downloads/#java24>, yet could not
reproduce the issue:

$ jdk-24.0.1/bin/jshell
|  Welcome to JShell -- Version 24.0.1
|  For an introduction type: /help intro

jshell> System.out.println("
|  Error:
|  unclosed string literal
|  System.out.println("
|

Would you mind sharing more details to reproduce the issue, please? Which
JDK distribution do you use? Which major/minor/patch version? Which
architecture & OS?

On Thu, Jun 12, 2025 at 9:19?PM Sven Reimers <sven.reimers at gmail.com> wrote:

> JDK 24
>
> Sven
>
> On Thu, Jun 12, 2025 at 8:56?PM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> What JDK version?
>>
>> On Thu, Jun 12, 2025 at 1:39?PM Sven Reimers <sven.reimers at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> working on highlighting in JTaccuino I found
>>>
>>> Caused by: java.lang.IllegalArgumentException
>>> at
>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:647)
>>> at
>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:627)
>>> at
>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.create(JCDiagnostic.java:301)
>>> at
>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.error(JCDiagnostic.java:114)
>>> at
>>> jdk.compiler/com.sun.tools.javac.util.AbstractLog.error(AbstractLog.java:145)
>>> at
>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.lexError(JavaTokenizer.java:202)
>>> at
>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.scanString(JavaTokenizer.java:468)
>>> at
>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.readToken(JavaTokenizer.java:1015)
>>> at
>>> jdk.compiler/com.sun.tools.javac.parser.Scanner.nextToken(Scanner.java:124)
>>> at
>>> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.lambda$highlights$0(SourceCodeAnalysisImpl.java:647)
>>> at
>>> jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$1(TaskFactory.java:218)
>>> at
>>> jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>>> at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:211)
>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:180)
>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:166)
>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:155)
>>> at
>>> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.highlights(SourceCodeAnalysisImpl.java:618)
>>>
>>> happening, when a snippet is sent with a not closed quoted string, e.g.
>>>
>>> System.out.println("
>>>
>>> I assume this should not happen?
>>>
>>> Thanks
>>>
>>> Sven
>>>
>>> --
>>> Sven Reimers
>>>
>>> * Java Champion
>>> * Apache NetBeans PMC: http://netbeans.apache.org
>>> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
>>>
>>
>>
>> --
>> Archie L. Cobbs
>>
>
>
> --
> Sven Reimers
>
> * Java Champion
> * Apache NetBeans PMC: http://netbeans.apache.org
> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
> * Duke's Choice Award Winner 2009 & 2018
>
> * LinkedIn: http://www.linkedin.com/in/svenreimers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250613/a44bb7ff/attachment-0001.htm>

From archie.cobbs at gmail.com  Fri Jun 13 16:56:57 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 13 Jun 2025 11:56:57 -0500
Subject: IllegalArgumentException in highlights
In-Reply-To: <CABDM8gBtvnZQMN7g6V02xd48j1oXi35wPFST1_Bzp08-2q53Ug@mail.gmail.com>
References: <CAP+Jvx7FJze=N7fam4-U8JsfArgYkY_rHbj3Dy7e_RyjK=+NEg@mail.gmail.com>
 <CANSoFxvkqMg_Ls_kHJ8wG4ZnS-Kfkfp8S+WZaQFU101ZaOr+VA@mail.gmail.com>
 <CAP+Jvx7W1Hk92dqPoHc832dhzHRYm-HY_rx_yxeVwi598-k1qA@mail.gmail.com>
 <CABDM8gBtvnZQMN7g6V02xd48j1oXi35wPFST1_Bzp08-2q53Ug@mail.gmail.com>
Message-ID: <CANSoFxusXoeom5h49jd4CzsTe7YrTBWcC5ZOF0ZQw0v+__NTMg@mail.gmail.com>

Here's a reproducer using JDK 25-ea:

$ jshell
|  Welcome to JShell -- Version 25-ea
|  For an introduction type: /help intro

jshell> import jdk.jshell.*

jshell> JShell jsh = JShell.builder().out(System.out).build();
jsh ==> jdk.jshell.JShell at 1134affc

jshell> var sca = jsh.sourceCodeAnalysis()
sca ==> jdk.jshell.SourceCodeAnalysisImpl at 73f792cf

jshell> sca.highlights("System.out.println(\"");
|  Exception java.lang.IllegalArgumentException
|        at JCDiagnostic.<init> (JCDiagnostic.java:659)
|        at JCDiagnostic.<init> (JCDiagnostic.java:641)
|        at JCDiagnostic$Factory.create (JCDiagnostic.java:294)
|        at JCDiagnostic$Factory.error (JCDiagnostic.java:111)
|        at AbstractLog.error (AbstractLog.java:144)
|        at JavaTokenizer.lexError (JavaTokenizer.java:201)
|        at JavaTokenizer.scanString (JavaTokenizer.java:470)
|        at JavaTokenizer.readToken (JavaTokenizer.java:1017)
|        at Scanner.nextToken (Scanner.java:124)
|        at SourceCodeAnalysisImpl.lambda$highlights$0
(SourceCodeAnalysisImpl.java:680)
|        at TaskFactory.lambda$runTask$1 (TaskFactory.java:218)
|        at JavacTaskPool.getTask (JavacTaskPool.java:193)
|        at TaskFactory.runTask (TaskFactory.java:211)
|        at TaskFactory.analyze (TaskFactory.java:180)
|        at TaskFactory.analyze (TaskFactory.java:166)
|        at TaskFactory.analyze (TaskFactory.java:155)
|        at SourceCodeAnalysisImpl.highlights
(SourceCodeAnalysisImpl.java:651)
|        at (#4:1)

Here's what happens:

   - JShell is doing some parsing without establishing the current source
   file via Log.useSource() (I've seen this in other JShell scenarios as
   well)
   - The JCDiagnostic() constructor has an assertion that if a diagnostic
   has a source code position then it also must have a current source file.

So the first question would be: who is right?

-Archie

On Fri, Jun 13, 2025 at 2:21?AM Volkan Yaz?c? <volkan at yazi.ci> wrote:

> Downloaded JDK 24.0.1
> <https://www.oracle.com/java/technologies/downloads/#java24>, yet could
> not reproduce the issue:
>
> $ jdk-24.0.1/bin/jshell
> |  Welcome to JShell -- Version 24.0.1
> |  For an introduction type: /help intro
>
> jshell> System.out.println("
> |  Error:
> |  unclosed string literal
> |  System.out.println("
> |
>
> Would you mind sharing more details to reproduce the issue, please? Which
> JDK distribution do you use? Which major/minor/patch version? Which
> architecture & OS?
>
> On Thu, Jun 12, 2025 at 9:19?PM Sven Reimers <sven.reimers at gmail.com>
> wrote:
>
>> JDK 24
>>
>> Sven
>>
>> On Thu, Jun 12, 2025 at 8:56?PM Archie Cobbs <archie.cobbs at gmail.com>
>> wrote:
>>
>>> What JDK version?
>>>
>>> On Thu, Jun 12, 2025 at 1:39?PM Sven Reimers <sven.reimers at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> working on highlighting in JTaccuino I found
>>>>
>>>> Caused by: java.lang.IllegalArgumentException
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:647)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:627)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.create(JCDiagnostic.java:301)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.error(JCDiagnostic.java:114)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.util.AbstractLog.error(AbstractLog.java:145)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.lexError(JavaTokenizer.java:202)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.scanString(JavaTokenizer.java:468)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.readToken(JavaTokenizer.java:1015)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.parser.Scanner.nextToken(Scanner.java:124)
>>>> at
>>>> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.lambda$highlights$0(SourceCodeAnalysisImpl.java:647)
>>>> at
>>>> jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$1(TaskFactory.java:218)
>>>> at
>>>> jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>>>> at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:211)
>>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:180)
>>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:166)
>>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:155)
>>>> at
>>>> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.highlights(SourceCodeAnalysisImpl.java:618)
>>>>
>>>> happening, when a snippet is sent with a not closed quoted string, e.g.
>>>>
>>>> System.out.println("
>>>>
>>>> I assume this should not happen?
>>>>
>>>> Thanks
>>>>
>>>> Sven
>>>>
>>>> --
>>>> Sven Reimers
>>>>
>>>> * Java Champion
>>>> * Apache NetBeans PMC: http://netbeans.apache.org
>>>> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
>>>>
>>>
>>>
>>> --
>>> Archie L. Cobbs
>>>
>>
>>
>> --
>> Sven Reimers
>>
>> * Java Champion
>> * Apache NetBeans PMC: http://netbeans.apache.org
>> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
>> * Duke's Choice Award Winner 2009 & 2018
>>
>> * LinkedIn: http://www.linkedin.com/in/svenreimers
>>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250613/430b858c/attachment.htm>

From sven.reimers at gmail.com  Fri Jun 13 21:41:23 2025
From: sven.reimers at gmail.com (Sven Reimers)
Date: Fri, 13 Jun 2025 23:41:23 +0200
Subject: IllegalArgumentException in highlights
In-Reply-To: <CANSoFxusXoeom5h49jd4CzsTe7YrTBWcC5ZOF0ZQw0v+__NTMg@mail.gmail.com>
References: <CAP+Jvx7FJze=N7fam4-U8JsfArgYkY_rHbj3Dy7e_RyjK=+NEg@mail.gmail.com>
 <CANSoFxvkqMg_Ls_kHJ8wG4ZnS-Kfkfp8S+WZaQFU101ZaOr+VA@mail.gmail.com>
 <CAP+Jvx7W1Hk92dqPoHc832dhzHRYm-HY_rx_yxeVwi598-k1qA@mail.gmail.com>
 <CABDM8gBtvnZQMN7g6V02xd48j1oXi35wPFST1_Bzp08-2q53Ug@mail.gmail.com>
 <CANSoFxusXoeom5h49jd4CzsTe7YrTBWcC5ZOF0ZQw0v+__NTMg@mail.gmail.com>
Message-ID: <CAP+Jvx6US8Exvtv0VONMDRX6myYs5_qHxqfb+tozL3kyxWOZgA@mail.gmail.com>

Hi,

thanks for the reproducer.

With

https://download.java.net/java/early_access/jdk26/docs/api/jdk.jshell/jdk/jshell/SourceCodeAnalysis.html#highlights(java.lang.String)

I would expect an empty list, if anything goes wrong, not an exception..

wdyt?

Sven

Archie Cobbs <archie.cobbs at gmail.com> schrieb am Fr., 13. Juni 2025, 18:57:

> Here's a reproducer using JDK 25-ea:
>
> $ jshell
> |  Welcome to JShell -- Version 25-ea
> |  For an introduction type: /help intro
>
> jshell> import jdk.jshell.*
>
> jshell> JShell jsh = JShell.builder().out(System.out).build();
> jsh ==> jdk.jshell.JShell at 1134affc
>
> jshell> var sca = jsh.sourceCodeAnalysis()
> sca ==> jdk.jshell.SourceCodeAnalysisImpl at 73f792cf
>
> jshell> sca.highlights("System.out.println(\"");
> |  Exception java.lang.IllegalArgumentException
> |        at JCDiagnostic.<init> (JCDiagnostic.java:659)
> |        at JCDiagnostic.<init> (JCDiagnostic.java:641)
> |        at JCDiagnostic$Factory.create (JCDiagnostic.java:294)
> |        at JCDiagnostic$Factory.error (JCDiagnostic.java:111)
> |        at AbstractLog.error (AbstractLog.java:144)
> |        at JavaTokenizer.lexError (JavaTokenizer.java:201)
> |        at JavaTokenizer.scanString (JavaTokenizer.java:470)
> |        at JavaTokenizer.readToken (JavaTokenizer.java:1017)
> |        at Scanner.nextToken (Scanner.java:124)
> |        at SourceCodeAnalysisImpl.lambda$highlights$0
> (SourceCodeAnalysisImpl.java:680)
> |        at TaskFactory.lambda$runTask$1 (TaskFactory.java:218)
> |        at JavacTaskPool.getTask (JavacTaskPool.java:193)
> |        at TaskFactory.runTask (TaskFactory.java:211)
> |        at TaskFactory.analyze (TaskFactory.java:180)
> |        at TaskFactory.analyze (TaskFactory.java:166)
> |        at TaskFactory.analyze (TaskFactory.java:155)
> |        at SourceCodeAnalysisImpl.highlights
> (SourceCodeAnalysisImpl.java:651)
> |        at (#4:1)
>
> Here's what happens:
>
>    - JShell is doing some parsing without establishing the current source
>    file via Log.useSource() (I've seen this in other JShell scenarios as
>    well)
>    - The JCDiagnostic() constructor has an assertion that if a diagnostic
>    has a source code position then it also must have a current source file.
>
> So the first question would be: who is right?
>
> -Archie
>
> On Fri, Jun 13, 2025 at 2:21?AM Volkan Yaz?c? <volkan at yazi.ci> wrote:
>
>> Downloaded JDK 24.0.1
>> <https://www.oracle.com/java/technologies/downloads/#java24>, yet could
>> not reproduce the issue:
>>
>> $ jdk-24.0.1/bin/jshell
>> |  Welcome to JShell -- Version 24.0.1
>> |  For an introduction type: /help intro
>>
>> jshell> System.out.println("
>> |  Error:
>> |  unclosed string literal
>> |  System.out.println("
>> |
>>
>> Would you mind sharing more details to reproduce the issue, please? Which
>> JDK distribution do you use? Which major/minor/patch version? Which
>> architecture & OS?
>>
>> On Thu, Jun 12, 2025 at 9:19?PM Sven Reimers <sven.reimers at gmail.com>
>> wrote:
>>
>>> JDK 24
>>>
>>> Sven
>>>
>>> On Thu, Jun 12, 2025 at 8:56?PM Archie Cobbs <archie.cobbs at gmail.com>
>>> wrote:
>>>
>>>> What JDK version?
>>>>
>>>> On Thu, Jun 12, 2025 at 1:39?PM Sven Reimers <sven.reimers at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> working on highlighting in JTaccuino I found
>>>>>
>>>>> Caused by: java.lang.IllegalArgumentException
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:647)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.<init>(JCDiagnostic.java:627)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.create(JCDiagnostic.java:301)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic$Factory.error(JCDiagnostic.java:114)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.util.AbstractLog.error(AbstractLog.java:145)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.lexError(JavaTokenizer.java:202)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.scanString(JavaTokenizer.java:468)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.parser.JavaTokenizer.readToken(JavaTokenizer.java:1015)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.parser.Scanner.nextToken(Scanner.java:124)
>>>>> at
>>>>> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.lambda$highlights$0(SourceCodeAnalysisImpl.java:647)
>>>>> at
>>>>> jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$1(TaskFactory.java:218)
>>>>> at
>>>>> jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
>>>>> at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:211)
>>>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:180)
>>>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:166)
>>>>> at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:155)
>>>>> at
>>>>> jdk.jshell/jdk.jshell.SourceCodeAnalysisImpl.highlights(SourceCodeAnalysisImpl.java:618)
>>>>>
>>>>> happening, when a snippet is sent with a not closed quoted string, e.g.
>>>>>
>>>>> System.out.println("
>>>>>
>>>>> I assume this should not happen?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Sven
>>>>>
>>>>> --
>>>>> Sven Reimers
>>>>>
>>>>> * Java Champion
>>>>> * Apache NetBeans PMC: http://netbeans.apache.org
>>>>> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
>>>>>
>>>>
>>>>
>>>> --
>>>> Archie L. Cobbs
>>>>
>>>
>>>
>>> --
>>> Sven Reimers
>>>
>>> * Java Champion
>>> * Apache NetBeans PMC: http://netbeans.apache.org
>>> * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee
>>> * Duke's Choice Award Winner 2009 & 2018
>>>
>>> * LinkedIn: http://www.linkedin.com/in/svenreimers
>>>
>>
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250613/0cc237d9/attachment-0001.htm>

From archie.cobbs at gmail.com  Fri Jun 13 21:52:52 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 13 Jun 2025 16:52:52 -0500
Subject: IllegalArgumentException in highlights
In-Reply-To: <CAP+Jvx6US8Exvtv0VONMDRX6myYs5_qHxqfb+tozL3kyxWOZgA@mail.gmail.com>
References: <CAP+Jvx7FJze=N7fam4-U8JsfArgYkY_rHbj3Dy7e_RyjK=+NEg@mail.gmail.com>
 <CANSoFxvkqMg_Ls_kHJ8wG4ZnS-Kfkfp8S+WZaQFU101ZaOr+VA@mail.gmail.com>
 <CAP+Jvx7W1Hk92dqPoHc832dhzHRYm-HY_rx_yxeVwi598-k1qA@mail.gmail.com>
 <CABDM8gBtvnZQMN7g6V02xd48j1oXi35wPFST1_Bzp08-2q53Ug@mail.gmail.com>
 <CANSoFxusXoeom5h49jd4CzsTe7YrTBWcC5ZOF0ZQw0v+__NTMg@mail.gmail.com>
 <CAP+Jvx6US8Exvtv0VONMDRX6myYs5_qHxqfb+tozL3kyxWOZgA@mail.gmail.com>
Message-ID: <CANSoFxuNBbKKZCx1LTUKc39_=cCu00KuPCkPriXvDJzukYXDQg@mail.gmail.com>

On Fri, Jun 13, 2025 at 4:41?PM Sven Reimers <sven.reimers at gmail.com> wrote:

> I would expect an empty list, if anything goes wrong, not an exception..
>

It's definitely a bug, but I'm not sure whose "fault" it is yet though
(i.e., JShell or the logging subsystem).

I created JDK-8359497 <https://bugs.openjdk.org/browse/JDK-8359497> to
track it.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250613/55f1cf71/attachment.htm>

From naoto at openjdk.org  Tue Jun 17 20:37:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Jun 2025 20:37:04 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
Message-ID: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>

Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

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

Commit messages:
 - Several more locations
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25860/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25860&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359732
  Stats: 69 lines in 13 files changed: 50 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25860.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25860/head:pull/25860

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

From achung at openjdk.org  Tue Jun 17 23:11:15 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:11:15 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
Message-ID: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>

This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

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

Commit messages:
 - empty commit
 - redo ws fixes, add manual changes

Changes: https://git.openjdk.org/jdk/pull/25839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359761
  Stats: 1574 lines in 76 files changed: 810 ins; 93 del; 671 mod
  Patch: https://git.openjdk.org/jdk/pull/25839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25839/head:pull/25839

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

From jlu at openjdk.org  Tue Jun 17 23:18:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:18:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

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

> 1: #
> 2: # Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights reserved.

Same as my comment in `src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java`

src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26:

> 24: #
> 25: 
> 26: main.usage=Verwendung: jdeprscan [Optionen] ''{dir|jar|class}'' ...\n\nOptionen:\n        --class-path PATH\n        --for-removal\n        --full-version\n  -? -h --help\n  -l    --list\n        --release {0}\n  -v    --verbose\n        --version

Extra quotes, applies to other localized versions as well. (Usual change we revert)

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

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

Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314389
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153313105
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153314152

From achung at openjdk.org  Tue Jun 17 23:18:27 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:18:27 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <-07gTVUiE_k1Kfc5m2OgDlX6fj1hUMYWZqsSK2YFlYc=.0fc07185-3be2-4f7c-b24f-fca061924170@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

whitespace changes are fixed, PR is ready for review

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2982077742

From jlu at openjdk.org  Tue Jun 17 23:24:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:24:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <41BnI9ePFiQiYk_COU-Rrpz0qzr33GN0p9AfF38Fkmk=.0d9c1020-d538-41b2-a939-f7e296029ae0@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 30:

> 28: STARNN=*******************************************\n\n
> 29: # keytool: Help part
> 30: .OPTION.=\ [OPTION]...

We spoke about this offline. This is fine, property file values need to either start with a `\ `or `\u0020` to denote intentional leading white space. In this case, since we convert to UTF-8 native characters from escape sequences this gets included as well. Functionally, they are equivalent and the new form works well with the translation process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153321343

From achung at openjdk.org  Tue Jun 17 23:34:52 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 17 Jun 2025 23:34:52 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  fix unicode escapes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/2dfac379..d8027691

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

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

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

From almatvee at openjdk.org  Tue Jun 17 23:43:28 2025
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 17 Jun 2025 23:43:28 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <uLYnpuvdWyGcO615myaP0lHZ9HMiX9Ag27OnViwh5Ik=.cb34bbec-542b-40a6-98ab-270e2b63bcae@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

jdk.jpackage changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2937331933

From naoto at openjdk.org  Wed Jun 18 01:56:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 01:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:

> 1: #

Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2153463170

From vyazici at openjdk.org  Wed Jun 18 07:10:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 18 Jun 2025 07:10:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <cyKIsynr19VsmvHUmvEFP9RP56GFxojjJVQezBM41lg=.1aea0985-9284-43b7-8537-6a46149de0fd@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

I've verified that all relevant occurrences of `std{in,err,out}.encoding` are covered, except the ones `src/java.base/share/classes/java/lang/System.java`, which, I presume, is left out intentionally.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2937989243

From alanb at openjdk.org  Wed Jun 18 07:55:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:55:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

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

> 285:         jdk.jpackage,
> 286:         jdk.jshell,
> 287:         jdk.net;

At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CLHSDB.java line 111:

> 109: 
> 110: 
> 111:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jhsdb tool, just wondering why it needs to be changed.

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

> 800:         }
> 801:         try {
> 802:             Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the example jdb debugger, I assume okay to let it read the stdin.encoding property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153907749
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153910478
PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153913162

From alanb at openjdk.org  Wed Jun 18 07:59:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Jun 2025 07:59:27 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <HS_moiW1ZXnwCePhJrtlJTtiwO37FEHMKxldVBPgDcw=.d649f3bf-3ce2-44d9-bc5c-9ed5f74b333d@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

src/java.scripting/share/classes/javax/script/SimpleScriptContext.java line 100:

> 98: 
> 99:     private static InputStreamReader stdinReader() {
> 100:         Charset charset = Charset.forName(StaticProperty.stdinEncoding(), Charset.defaultCharset());

This is the jrunscript command line tool. I suppose it's possible it could run a script that changes stdin.encoding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2153921907

From nbenalla at openjdk.org  Wed Jun 18 09:08:29 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 18 Jun 2025 09:08:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <xcSAVqLxI2phW8UCEHcDpUMeFySiy0zigXx-MPkt5aU=.0c203d6f-60e1-41d1-82d5-a93bba898f5f@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

I'm unable to confirm the accuracy of the translations, since I don't speak the target languages. I've only reviewed the `jdk.javadoc` sources.

All keys in the English property files match one-to-one with those in the non-English files: there are no missing or extra entries. The only changes are to the `.properties` files, exactly as the PR title suggests.

>From the `jdk.javadoc` perspective, this looks good, so I'm happy to approve this PR.

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

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2938377311

From duke at openjdk.org  Wed Jun 18 09:41:35 2025
From: duke at openjdk.org (duke)
Date: Wed, 18 Jun 2025 09:41:35 GMT
Subject: Withdrawn: 8352693: Use a simpler console reader instead of JLine for
 System.console()
In-Reply-To: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
References: <V5VUSrF8Bcn5UmBaYxWW18CoKgCtTABT_4Q71zlDmpo=.a6165b5a-7a95-4722-9871-cd9c662919bb@github.com>
Message-ID: <2x0dTfpcu1MdxTVpRSizOlN_dEsobjFzk2uXRNu3-D0=.06f77c08-90d1-4b0c-8aab-603eb1d530bb@github.com>

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

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

This pull request has been closed without being integrated.

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

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

From jsikstro at openjdk.org  Wed Jun 18 09:50:30 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 18 Jun 2025 09:50:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2983504760

From rriggs at openjdk.org  Wed Jun 18 15:08:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:28 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
Message-ID: <LbRBF6gknL_SsjFh_wALuLuFGTOFzDNYTUikL7MbvA8=.f0b9e433-da69-4280-9a3d-9150dfaa1b80@github.com>

On Tue, 17 Jun 2025 20:16:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.

Static properties should not be used outside of java.base.
The "for internal use only" should have said "java.base internal use only"
Adding a comment to that effect would be a good idea.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25860#pullrequestreview-2939624079

From rriggs at openjdk.org  Wed Jun 18 15:08:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Jun 2025 15:08:30 GMT
Subject: RFR: 8359732: Make standard i/o encoding related system properties
 `StaticProperty`
In-Reply-To: <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
References: <uqA3VNfa74QYoeC6QPnXEGRqieWxLw3Z6sDqDm-6dgc=.a21207e1-e732-4f20-9c9c-ab1f0a0e01e2@github.com>
 <dViJkSq-Fnckq_r2ODs-kuYsCDfGhe2rX3BZS9h255c=.ae48363a-f6a2-4b91-9455-c66c512f303a@github.com>
Message-ID: <0gpDp3XapnEa-4BfqTDt7AAHV7_qDLoKHy3-2xzJ7ro=.faa1279d-82a8-4a68-a026-94f325f904e7@github.com>

On Wed, 18 Jun 2025 07:50:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Refactored the internal handling of `stdin/out/err.encoding` to allow setting them only via command-line options by converting them into `StaticProperty`. This change prevents unexpected behavior caused by applications modifying these properties at runtime using `System.setProperty()`.
>
> src/java.base/share/classes/module-info.java line 287:
> 
>> 285:         jdk.jpackage,
>> 286:         jdk.jshell,
>> 287:         jdk.net;
> 
> At some point we will need to re-visit all these qualified exports so that java.base exports as few of these internal packages as possible.

The original intent of StaticProperties was to limit it to the base module.
Other modules are free to read the property themselves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25860#discussion_r2154852609

From aivanov at openjdk.org  Wed Jun 18 16:15:35 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:15:35 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
Message-ID: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>

On Tue, 17 Jun 2025 23:34:52 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix unicode escapes

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:

> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.

Shall the copyright year be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:

> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
> 459: SliderDemo.majorticks=Grobteilungen
> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen

Should the translation of `SliderDemo.majorticks` also be updated?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

The following description uses different words now:

Feinteilungen -> Teilstrichen
Teilungen -> Teilstrichen

src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:

> 181: size.bit.alg=%1$d-Bit-%2$s
> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}

It feels as if there's something missing after _?einem?_.

src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46:

> 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben
> 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben
> 46: Subject.=Subject:\n

Is it correct? German usually uses `k`.

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:

> 54: 
> 55: # javax.security.auth.login.AppConfigurationEntry
> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020

Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:

> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:

Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:

> 227: doclet.search_in_documentation=In Dokumentation suchen
> 228: doclet.search_reset=Zur?cksetzen
> 229: doclet.Member=Member

Is `Member` translated? Should it be _?Mitglied?_?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154931256
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154807291
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154813672
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154907979
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154905960
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154915395
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154968902
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2154985100

From jlu at openjdk.org  Wed Jun 18 16:24:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:24:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <epU16E3XQ7BNcECTdZbJJpdFw05jYxEZ8Kt1yRx34nY=.a5624636-51ea-4466-83c2-6e0f7aa6aca1@github.com>

On Wed, 18 Jun 2025 15:28:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
> 
>> 54: 
>> 55: # javax.security.auth.login.AppConfigurationEntry
>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
> 
> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.

There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155032074

From jlu at openjdk.org  Wed Jun 18 16:28:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Jun 2025 16:28:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>

On Wed, 18 Jun 2025 15:34:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
> 
>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Shall the copyright year be updated?

In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155038247

From aivanov at openjdk.org  Wed Jun 18 16:45:29 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 16:45:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
Message-ID: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>

On Wed, 18 Jun 2025 16:25:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 1:
>> 
>>> 1: # Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Shall the copyright year be updated?
>
> In the past, we usually don't modify the copyright years and the translation team syncs the localized variants with the original file. In this case the original file did not have a change, simply the translations were updated with a "newer version".

This is weird? Usually, the copyright year is bumped up whenever the file is edited.

>> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 56:
>> 
>>> 54: 
>>> 55: # javax.security.auth.login.AppConfigurationEntry
>>> 56: LoginModuleControlFlag.=LoginModuleControlFlag?\u0020
>> 
>> Is it intended to have two spaces instead of one? Or am I missing anything? The colon on the modified line looks slightly differently.
>
> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.

Thank you for clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071387
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155071915

From naoto at openjdk.org  Wed Jun 18 16:58:34 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Jun 2025 16:58:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <zJCQh_R1fU5XdBZNfVyW5e-hk_mRcfnjPASPqzu-t3s=.8b34a54f-3ae2-4516-a2b6-d5c32b3891b8@github.com>
Message-ID: <GMreFXOIVIHSDY6c8Vcze6uvKnnsOAaNIH6G5rBfkQA=.507f3521-b8a6-4024-a1ed-d41f71a9c1e1@github.com>

On Wed, 18 Jun 2025 09:47:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Should the other localizations for the launcher help text (in `launcher_<lang>.properties`) also be updated? I see that only the German, Japanese and Chinese localizations have been updated so far.

Those languages (de/ja/zh-CN) are the ones we (Oracle) support. Other entities would be welcome to provide l10n for other languages (not a sporadic l10n, but commit to update/maintain).

> 
> Edit: I see that the other localizations haven't been updated for the last few releases, so maybe this is intentional. Still interested to know why we have the other localizations if they aren't updated.

Usuallly l10n resource updates are additions, so those old l10ns still have values for those languages. New additions will simply fall back to English.

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-2985038815

From achung at openjdk.org  Wed Jun 18 18:42:54 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 18 Jun 2025 18:42:54 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <3Sb_Nj53MtMZRoKypbBFn0yumsFtiGJzY5fv60CilwA=.4ee9201b-0657-484b-8e69-01306c131b39@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung 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/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/d8027691..66c34e7d

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

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

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

From dnguyen at openjdk.org  Wed Jun 18 18:50:29 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 18 Jun 2025 18:50:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
Message-ID: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>

On Tue, 17 Jun 2025 23:15:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Alisen Chung 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 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.

Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155272483

From prr at openjdk.org  Wed Jun 18 20:40:29 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 18 Jun 2025 20:40:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>

On Wed, 18 Jun 2025 14:45:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
> 
>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>> 459: SliderDemo.majorticks=Grobteilungen
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 
> Should the translation of `SliderDemo.majorticks` also be updated?

I agree. I'd expect consistency here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2155451453

From duke at openjdk.org  Thu Jun 19 17:42:30 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 19 Jun 2025 17:42:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>

On Wed, 18 Jun 2025 15:25:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
> 
>> 181: size.bit.alg=%1$d-Bit-%2$s
>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
> 
> It feels as if there's something missing after _?einem?_.

seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2157444024

From manderse at redhat.com  Sun Jun 22 09:11:47 2025
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sun, 22 Jun 2025 11:11:47 +0200
Subject: difference in behaviour with import module java.base
Message-ID: <CAHL=7VvXDv0MKy+aGL2JATKOU07xp9E_SQ_nzjXQSAJZLXuXEQ@mail.gmail.com>

Hi,

I got reported a "fun" issue on jbang
https://github.com/jbangdev/jbang/issues/2072 which boils down to the
following calls to jshell behaving differently for reasons I can't really
explain.

I've boiled it down to what *looks* like a bug/change of behaviour and
wondering if intentional or not:

Take this code and put in test.jsh (you can also manually type it but whats
the fun in that):

String[] args = { "arg1", "arg2" }
import module java.base;
import static java.util.stream.Collectors.*;
System.out.println(args.length);
/exit

now run this using:

jshell --enable-preview -J--enable-preview --startup=DEFAULT
--execution=local test.jsh

And you will get printed:
2

the correct length of the args array.

Now change it to:

String[] args = { "arg1", "arg2" }
import static java.util.stream.Collectors.*;
import module java.base;
System.out.println(args.length);
/exit

Note, the import order is changed.

Now you get:

WARNING: Using incubator modules: jdk.incubator.vector
Exception java.lang.NullPointerException: Cannot read the array length
because "REPL.$JShell$11B.args" is null
      at (#4:1)

question is why is this happening?

Also, if you remove `--startup=DEFAULT` OR `--execution=local` the
behaviour stays the same and 2 is printed in all cases.

Bug or expected ?

Hope it all makes sense :)

-- 
/max
https://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250622/e85a050f/attachment-0001.htm>

From henryjen at openjdk.org  Mon Jun 23 07:34:32 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 23 Jun 2025 07:34:32 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
Message-ID: <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>

On Wed, 18 Jun 2025 01:51:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:
> 
>> 1: #
> 
> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.

I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
If that was intentionally left out, I don't see new reason to add them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2160914804

From manderse at redhat.com  Sun Jun 22 09:02:51 2025
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sun, 22 Jun 2025 11:02:51 +0200
Subject: behaviour difference in java 24 when using imports...
Message-ID: <CAHL=7VvPFOr51Bi9Rje9F7YTEXaK79M+MnMTnQ-f25=4pduFig@mail.gmail.com>

Hi,

I got reported a "fun" issue on jbang
https://github.com/jbangdev/jbang/issues/2072 which boils down to the
following calls to jshell behaving differently for reasons I can't really
explain.

I've boiled it down to what *looks* like a bug/change of behaviour and
wondering if intentional or not:

Take this code and put in test.jsh (you can also manually type it but whats
the fun in that):

String[] args = { "arg1", "arg2" }
import module java.base;
import static java.util.stream.Collectors.*;
System.out.println(args.length);
/exit

now run this using:

jshell --enable-preview -J--enable-preview --startup=DEFAULT
--execution=local test.jsh

And you will get printed:
2

the correct length of the args array.

Now change it to:

String[] args = { "arg1", "arg2" }
import static java.util.stream.Collectors.*;
import module java.base;
System.out.println(args.length);
/exit

Note, the import order is changed.

Now you get:

WARNING: Using incubator modules: jdk.incubator.vector
Exception java.lang.NullPointerException: Cannot read the array length
because "REPL.$JShell$11B.args" is null
      at (#4:1)

question is why is this happening?

Also, if you remove `--startup=DEFAULT` OR `--execution=local` the
behaviour stays the same and 2 is printed in all cases.

Bug or expected ?

Hope it all makes sense :)

--
/max
https://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250622/617087c4/attachment.htm>

From jlu at openjdk.org  Mon Jun 23 14:45:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 14:45:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v3]
In-Reply-To: <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <Cje6gKMQPt1zWBjiAY8j2JlM_29ACoaUVursuJyp_1E=.c55575ca-5cc2-422a-9694-cc7acd41804c@github.com>
 <dWF_2vYxbax6VWDCokd4Mlhsn3H7PV3crLJAofEfr90=.231f96e1-6130-41f4-abc5-53166ca93f48@github.com>
Message-ID: <BVN8gdSxc54F_PWYYXyMoHt4FDCeFNtN_vMeMSxIGoI=.beedc45e-7447-4e77-9553-ad1420bc512e@github.com>

On Wed, 18 Jun 2025 18:48:04 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2001, 2023, Oracle and/or its affiliates. All rights reserved.
>> 
>> Looks wrong but is correct. File had its copyright year updated in https://bugs.openjdk.org/browse/JDK-8345800, but the original is still 2023. Translation team is re-syncing it to match the original year.
>
> Is there any way to prevent this or do we just change it back when we do a drop and explain why each time?

If this is committed, then the years will be synced and we won't have to change it back. This would be consistent with the way we receive l10n translations which sync the copyright years of localized files to the original. 

If we want to deviate from this then we could file a request asking them to not update copyright years and we could update them ourselves.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161805058

From jlu at openjdk.org  Mon Jun 23 14:57:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 14:57:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>

On Wed, 18 Jun 2025 15:52:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:
> 
>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:
> 
> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.

I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161832785

From jlu at openjdk.org  Mon Jun 23 15:00:37 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Jun 2025 15:00:37 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <M5xHiXsy_RXNKRklp3u-Rc0JJiVmUyKDAdZgTmURWbo=.3c8874b7-ffda-4ffe-910f-381607b78e29@github.com>

On Wed, 18 Jun 2025 15:59:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 229:
> 
>> 227: doclet.search_in_documentation=In Dokumentation suchen
>> 228: doclet.search_reset=Zur?cksetzen
>> 229: doclet.Member=Member
> 
> Is `Member` translated? Should it be _?Mitglied?_?

Good catch. Usually, we file these issues with the translation team and make the appropriate updates in the second L10n drop. I think this one is fine to be updated now as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2161839290

From achung at openjdk.org  Mon Jun 23 16:38:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
Message-ID: <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>

On Wed, 18 Jun 2025 14:48:13 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix unicode escapes
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:
> 
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
>> 462: SliderDemo.minorticks=Feinteilungen
> 
> The following description uses different words now:
> 
> Feinteilungen -> Teilstrichen
> Teilungen -> Teilstrichen

Just to clarify, does this mean

SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels
SliderDemo.minorticks=Teilstrichen

is correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162030543

From achung at openjdk.org  Mon Jun 23 16:38:29 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
Message-ID: <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>

On Wed, 18 Jun 2025 20:37:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 460:
>> 
>>> 458: SliderDemo.a_plain_slider=Ein einfacher Schieberegler
>>> 459: SliderDemo.majorticks=Grobteilungen
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 
>> Should the translation of `SliderDemo.majorticks` also be updated?
>
> I agree. I'd expect consistency here.

What would be the correct translation of majorticks here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162027420

From achung at openjdk.org  Mon Jun 23 16:38:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
 <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
Message-ID: <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>

On Mon, 23 Jun 2025 07:31:34 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties line 1:
>> 
>>> 1: #
>> 
>> Just wondering why this resource file has not been translated into de/ja/zh_CN till now. Looks correct though.
>
> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
> If that was intentionally left out, I don't see new reason to add them.

This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162024606

From achung at openjdk.org  Mon Jun 23 16:44:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:44:23 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  update to german translations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/66c34e7d..90bfd7bd

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

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

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

From naoto at openjdk.org  Mon Jun 23 16:44:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Jun 2025 16:44:24 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <BF4ypBPsudR5UfcpmFRzHx4Xd_p2cBRj2LAC03wzbVs=.78a79e87-2808-40c0-b64b-795b526f366b@github.com>
 <KIsmHFx2cVbJJ-DDbarwf9NVbONDqpQr9BckHVXsZpA=.62a82ba6-00f5-4113-8d24-5d60ce5c47da@github.com>
 <mX5C6udFi0d1gR80HpyQ9-9t-cf7fMUxdf1bDmLcxxE=.e343b549-8696-46b8-a7e9-4285bdc5d46d@github.com>
Message-ID: <i1GseMJyfCL5uo-smr3SLsDUVkvWzdQheIzvVr5PpKY=.1281d6d5-c07e-47cc-bacc-8ea1161a3df9@github.com>

On Mon, 23 Jun 2025 16:32:21 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I am wondering the same thing. Perhaps because it is not intended for general public, it's not in the [JDK tools specifications](https://docs.oracle.com/en/java/javase/24/docs/specs/man/index.html).
>> If that was intentionally left out, I don't see new reason to add them.
>
> This file wasn't originally in the tbom file when we first restarted translations and was picked up by our getChanges tool because of a recent update to the file some time after the previous drop, so it hasn't been translated until this drop. Maybe the previous team just forgot to translate this file?

Thanks. I guess this was simply an overlook in the first place, as the process was manual back then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162038459

From duke at openjdk.org  Mon Jun 23 17:41:29 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Mon, 23 Jun 2025 17:41:29 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
Message-ID: <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>

On Mon, 23 Jun 2025 16:34:05 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> I agree. I'd expect consistency here.
>
> What would be the correct translation of majorticks here?

If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162131034

From aivanov at openjdk.org  Mon Jun 23 18:45:30 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 18:45:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <odr9SLW6_8t2_QsZRndgYFqyCZTVjXh6U6rnT_fL3uQ=.404af4de-b837-485e-a220-47419742434d@github.com>
Message-ID: <9FQIYMoH-HEi7ktEzRGxRsoWXGPsDyWPWk3Ds0Edjy0=.5dcab616-2713-441b-b363-350ea62505e3@github.com>

On Mon, 23 Jun 2025 14:55:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 220:
>> 
>>> 218: entry.1.is.signed.in.jarfile.but.is.not.signed.in.jarinputstream=Eintrag %s ist in JarFile, aber nicht in JarInputStream signiert
>>> 219: entry.1.is.signed.in.jarinputstream.but.is.not.signed.in.jarfile=Eintrag %s ist in JarInputStream, aber nicht in JarFile signiert
>>> 220: jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream=Diese JAR-Datei enth?lt interne Inkonsistenzen, die zu anderem Inhalt beim Lesen ?ber JarFile als beim Lesen ?ber JarInputStream f?hren k?nnen:
>> 
>> Is it expected to have ?JAR_-Datei_?? It was removed from `.verified` and `.signed` strings.
>
> I think it is because the English version of the properties file uses "jar" for `.verified` and `.signed` strings, but `jar.contains.internal.inconsistencies.result.in.different.contents.via.jarfile.and.jarinputstream` uses "JAR".

I see the entries for


jar.signed.=jar signed.
jar.verified.=jar verified.

don't have the word *?file?*, whereas `?via.jarfile.and.jarinputstream` has it: ?This JAR *file*??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162318454

From aivanov at openjdk.org  Mon Jun 23 19:07:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:07:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
 <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
Message-ID: <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>

On Mon, 23 Jun 2025 17:38:58 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> What would be the correct translation of majorticks here?
>
> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").

Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162350461

From aivanov at openjdk.org  Mon Jun 23 19:36:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:36:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <OZ262_JSW2vfezx4xU16MrfrecafkpCY6BuoG8nJgkU=.8ea6aecc-dd18-4799-a844-6139910d7aea@github.com>
Message-ID: <O9Co_nchUBZcx7IsEWV3BulBeBx49f1DCSSfMncRP9Y=.01ec06db-951c-4466-b07e-4f49e34c41ad@github.com>

On Mon, 23 Jun 2025 16:36:00 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:
>> 
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>>> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
>>> 462: SliderDemo.minorticks=Feinteilungen
>> 
>> The following description uses different words now:
>> 
>> Feinteilungen -> Teilstrichen
>> Teilungen -> Teilstrichen
>
> Just to clarify, does this mean
> 
> SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels
> SliderDemo.minorticks=Teilstrichen
> 
> is correct?

Hm? I don't know. You should clarify with the translation team. They've changed the translation for the major ticks from *Grobteilungen* to *Hauptteilstriche*. Yet minor ticks remain *Feinteilungen*, which doesn't look right because the main word is different. (*Teilung* doesn't seem to be the right word, at least dictionaries translate it as ?division?.)

*Teilstrich* means *scale line*, the marks on a ruler, so it fits.

Microsoft documentation for [MinorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.minortickmark?view=openxml-3.0.1) uses *Kleinere Teilstriche*, yet I don't understand why there's ?-e? ending (plural?).


SliderDemo.ticks=Teilstrichen, Teilstrichen zum Einrasten und Labels

This one looks particularly incorrect; ?einrasten? is a verb with a separable prefix that means ?to lock?, and I can't find a usage as if it's a noun.

The English phrase is ?Minor Ticks, Snap-to-ticks and Labels?, and I don't know how to correctly translate it to German.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162394521

From aivanov at openjdk.org  Mon Jun 23 19:36:32 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:36:32 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <yC5NAA2uzq92MZGyXJQkRYallBsQCJpF8vmemkndk9c=.c7bb4cff-9af0-4d25-9782-dbe35cafcfd8@github.com>
Message-ID: <Cnn1pTxh334i_8vCnBa3c3FWvblGyzCjASOEGJQTsw8=.eb5e76f7-e83b-416c-9fe6-361d772780af@github.com>

On Thu, 19 Jun 2025 17:39:38 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/resources/keytool_de.properties line 183:
>> 
>>> 181: size.bit.alg=%1$d-Bit-%2$s
>>> 182: Generating.full.keyAlgName.key.pair.and.self.signed.certificate.sigAlgName.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und selbstsigniertem Zertifikat ({1}) mit einer G?ltigkeit von {2} Tagen\n\tf?r: {3}
>>> 183: Generating.full.keyAlgName.key.pair.and.a.certificate.sigAlgName.issued.by.signerAlias.with.a.validity.of.days.for=Generieren von {0}-Schl?sselpaar und einem von <{2}> ausgestellten Zertifikat ({1}) mit einer G?ltigkeit von {3} Tagen\n\tf?r: {4}
>> 
>> It feels as if there's something missing after _?einem?_.
>
> seems ok to me, einem von X ausgestellten Zertifikat ~ einem Zertifikat, das von X ausgestellt wurde

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162395125

From cstein at openjdk.org  Tue Jun 24 05:15:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:15:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <a_GmJUtJTOEwCYk23UOkb03IWqfwuNI0GO1lXRJTGGY=.06afc484-9259-46d4-9384-9e93b08598c0@github.com>
 <wjxC1HjQZ0pqyW-twJYYAjL6gH44ufgW53nkbNSLHRI=.848fbbb0-ebe7-4c55-9ae3-2996471c368c@github.com>
 <KD-oruGQL9hUtmCexnxFdfMwwEud0SQCNo4HMW4l9-o=.37a8bead-5fe1-42b8-887e-fbe834794531@github.com>
 <OcacegwRzvpCkX4TBo0MwjR50O63wyiITIe63m_Qd3Y=.2afba7d1-f27a-4978-b495-01a995eb545e@github.com>
Message-ID: <bNn_SZAJQvbgRD39f2sJDCLItuz4Q-fJOjCQzc0URAo=.825ec4ad-31a1-4882-93ee-97f0eff02597@github.com>

On Mon, 23 Jun 2025 19:04:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> If "major tick" is translated to "Hauptteilstrich", then the plural would be `[SliderDemo.majorticks=]Hauptteilstriche` (which is a rather artificial word so the translation team might want to come up with a better translation for "major tick").
>
> Microsoft uses *Hauptteilstrich*, see [MajorTickMark Klasse](https://learn.microsoft.com/de-de/dotnet/api/documentformat.openxml.drawing.charts.majortickmark?view=openxml-3.0.1), so *Hauptteilstrich* (singular Nominative) seems correct.

Ja, "Hauptteilstrich" and "Hauptteilstriche" (pl) are correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162975420

From cstein at openjdk.org  Tue Jun 24 05:22:33 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:22:33 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <ws3HlD1kGmF5lUjtCE7SxWmnc4GEkdFi6FWo_Hnm7Tc=.c3dc65c9-7681-4145-afc2-a3af84857e78@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 462:

> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Feinteilungen, Teilungen zum Einrasten und Labels
> 462: SliderDemo.minorticks=Feinteilungen

For consistency with the "Hilfsteilstrich" (singular) and "Hilfsteilstriche" (plural) used below in `SliderDemo.minorticksdescription` and `SliderDemo.disableddescription`, I'd suggest to use:
Suggestion:

SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
SliderDemo.minorticks=Hilfsteilstriche


As "Labels" is not a German word.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162982972

From cstein at openjdk.org  Tue Jun 24 05:34:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:34:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <8Orj0J7-iUsSjTQEc7t-pSShM2wHGmfReMStzGByHGY=.41967017-0e70-4e2a-9133-f84fd263ff51@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 178:

> 176: javac.opt.Xlint.desc.restricted=Warnt vor der Verwendung eingeschr?nkter Methoden.
> 177: 
> 178: javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n                         Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "Identit?t", die dieselben Verwendungen und\n                         Effekte hat. Benutzern wird empfohlen, die Kategorie "Identit?t" f?r alle zuk?nftigen\n                         und vorhandenen Verwendungen von "Synchronisierung" zu verwenden.

"Identit?t" and "Synchronisierung" are literals that must not be translated.

The English base entry reads:


javac.opt.Xlint.desc.synchronization=\
    Warn about synchronization attempts on instances of value-based classes.\n\
\                         This key is a deprecated alias for ''identity'', which has the same uses and\n\
\                         effects. Users are encouraged to use the ''identity'' category for all future\n\
\                         and existing uses of ''synchronization''.


And `javac --help-lint` contains:


    strictfp             Warn about unnecessary use of the strictfp modifier.
    synchronization      Warn about synchronization attempts on instances of value-based classes.
    text-blocks          Warn about inconsistent white space characters in text block indentation.
    
    
    
Suggestion:

javac.opt.Xlint.desc.synchronization=Warnt vor Synchronisierungsversuchen mit Instanzen wertbasierter Klassen.\n                         Dieser Schl?ssel ist ein veralteter Alias f?r die Kategorie "identity", die dieselben Verwendungen und\n                         Effekte hat. Benutzern wird empfohlen, die Kategorie "identity" f?r alle zuk?nftigen\n                         und vorhandenen Verwendungen von "synchronization" zu verwenden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2162995954

From cstein at openjdk.org  Tue Jun 24 05:44:30 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Jun 2025 05:44:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <AQix03HSJOPQl9dpzNexQJ-oAj3KLVWEt4zDGOxjmZM=.1efb1178-489f-478e-9534-f9b32e5b92de@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties line 103:

> 101: 
> 102: # 0: string
> 103: launcher.err.cant.find.main.method=main(String[])- oder main()-Methode nicht gefunden in Klasse: {0}

Suggestion:

launcher.err.cant.find.main.method=Konnte keine main(String[])- oder main()-Methode in der Klasse: {0} finden.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2163006433

From weijun at openjdk.org  Tue Jun 24 14:56:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 14:56:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
Message-ID: <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>

On Wed, 18 Jun 2025 16:43:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> There is still only one space, the new one is a full width colon (U+FF1A). Localization rules have been observed to make the switch from regular colons (U+003A) into the full width version depending on the language.
>
> Thank you for the clarification.

However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164251035

From weijun at openjdk.org  Tue Jun 24 15:01:30 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 15:01:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
Message-ID: <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>

On Mon, 23 Jun 2025 16:44:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update to german translations

src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:

> 47: .Principal.=\t????\u0020
> 48: .Public.Credential.=\t??????:\u0020
> 49: .Private.Credential.=\t??????:\u0020

Why aren't the 2 lines above updated like in lines 46 and 47?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164262664

From weijun at openjdk.org  Tue Jun 24 15:01:31 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 24 Jun 2025 15:01:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
 <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
Message-ID: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>

On Tue, 24 Jun 2025 14:54:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Thank you for the clarification.
>
> However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".

Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2164261187

From archie.cobbs at gmail.com  Tue Jun 24 17:37:18 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 24 Jun 2025 13:37:18 -0400
Subject: difference in behaviour with import module java.base
In-Reply-To: <CAHL=7VvXDv0MKy+aGL2JATKOU07xp9E_SQ_nzjXQSAJZLXuXEQ@mail.gmail.com>
References: <CAHL=7VvXDv0MKy+aGL2JATKOU07xp9E_SQ_nzjXQSAJZLXuXEQ@mail.gmail.com>
Message-ID: <CANSoFxsS4V6V4O0=4ye8NX-U6RqKahg-511Kjvyyk4qyAOPHfA@mail.gmail.com>

Hi Max,

On Sun, Jun 22, 2025 at 5:12?AM Max Rydahl Andersen <manderse at redhat.com>
wrote:

> I got reported a "fun" issue on jbang
> https://github.com/jbangdev/jbang/issues/2072 which boils down to the
> following calls to jshell behaving differently for reasons I can't really
> explain.
>

I'm having trouble reproducing this.

$ cat test.jsh
String[] args = { "arg1", "arg2" }
import static java.util.stream.Collectors.*;
import module java.base;
System.out.println(args.length);
/exit
$ java -version
openjdk version "25-ea" 2025-09-16
OpenJDK Runtime Environment (build 25-ea+26-3358)
OpenJDK 64-Bit Server VM (build 25-ea+26-3358, mixed mode, sharing)
$ jshell --enable-preview -J--enable-preview --startup=DEFAULT
--execution=local test.jsh
2
$

Does that test look correct? I'm running on Mac OS (Arm) and I tried with
23, 24, and 25-ea.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20250624/7551f3be/attachment.htm>

From achung at openjdk.org  Tue Jun 24 21:47:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 24 Jun 2025 21:47:23 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v5]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <D5DGFra1xHGKB6ITrD1TV1PQcZNS_7nlA8GfD8cwQ6w=.c87859b8-fb89-4d2e-93a4-d9c0e3e44f21@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/90bfd7bd..97f3fe37

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

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

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

From dnguyen at openjdk.org  Wed Jun 25 00:30:31 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 25 Jun 2025 00:30:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
Message-ID: <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>

On Tue, 24 Jun 2025 14:59:18 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to german translations
>
> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:
> 
>> 47: .Principal.=\t????\u0020
>> 48: .Public.Credential.=\t??????:\u0020
>> 49: .Private.Credential.=\t??????:\u0020
> 
> Why aren't the 2 lines above updated like in lines 46 and 47?

I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.

I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2165200706

From jlu at openjdk.org  Wed Jun 25 17:01:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 17:01:42 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
 <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
Message-ID: <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>

On Wed, 25 Jun 2025 00:27:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/resources/security_zh_CN.properties line 49:
>> 
>>> 47: .Principal.=\t????\u0020
>>> 48: .Public.Credential.=\t??????:\u0020
>>> 49: .Private.Credential.=\t??????:\u0020
>> 
>> Why aren't the 2 lines above updated like in lines 46 and 47?
>
> I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.
> 
> I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.

If the context for these 2 values makes sense to use the full-width colon then let's update them here and we can file an issue with the translation team to get them synced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167196792

From achung at openjdk.org  Wed Jun 25 17:08:20 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 17:08:20 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:

 - update majorticks translation
 - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
 - fix colon in chinese security.properties file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/97f3fe37..67990651

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

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

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

From achung at openjdk.org  Wed Jun 25 17:14:30 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 17:14:30 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v4]
In-Reply-To: <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <0TCi0COBOv8n_PJEC7NpYpDEjwqZ_3Y8_GtOfYETI1Q=.2b1705fb-1afc-4ec5-8be2-d7bef70fa562@github.com>
 <WHNIK6WQ1Y5x33W8vaKCXZJ5MJjM40ODNx2cBohFtpQ=.434218f1-9099-4045-b90f-0c13a5a4a5dd@github.com>
 <EkV9jV9XTsut84ob-HuMVzhJzQYhFVWWjmPlA-p1ewU=.b85e2289-4e2b-437e-944c-7bb5aadfc0c0@github.com>
 <8VlBIQujie_ZC5DVQHE_1GWD2RG8z6TZw2Vui2aOSEo=.dfd5df61-faab-4a95-b11b-125c8865d84e@github.com>
Message-ID: <CMnvjWZDePPSAZ69wSOKZLnscDx2R5vNhJAw1OkZTi8=.c81ae441-6667-41df-8e84-2eeec2fb3d15@github.com>

On Wed, 25 Jun 2025 16:59:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> I checked the ASCII codes here and on the source file. The updated colons are localized to full-width colons as @justin-curtis-lu mentioned in another thread here.
>> 
>> I agree. I also believe lines 48 & 49 need to be updated to the same type of colon. I don't see a good reason for why this was not updated as well. We may need to file a bug with the translators to resolve this inconsistency for next time. We should update these lines here now unless anyone else sees a reason not to.
>
> If the context for these 2 values makes sense to use the full-width colon then let's update them here and we can file an issue with the translation team to get them synced.

There's more full width colons spread around in different properties files and I think the translation team just revisits lines and decides to change the colon, so these changes look a bit random to us. I've updated these specific colons to full width for now but I think it might be better to just let the translation team update them for each drop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167222866

From achung at openjdk.org  Wed Jun 25 20:22:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 20:22:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
Message-ID: <Bot3EolwZjhUb3m62TbiB2D7LtowSu6VLXRIBmM2XfI=.92f0274b-629b-4b02-b25e-ecb71ff7f3c8@github.com>

On Wed, 25 Jun 2025 17:08:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update majorticks translation
>  - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
>  - fix colon in chinese security.properties file

Currently running tests and everything looks green so far, @aivanov-jdk @sormuras do the German localizations look fine?

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

PR Comment: https://git.openjdk.org/jdk/pull/25839#issuecomment-3006029100

From jlu at openjdk.org  Wed Jun 25 21:19:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 21:19:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v6]
In-Reply-To: <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <A8-dFBI2Gk-VdqR_l4lwojVF5CZvIJ2ULOlDgHiSbNc=.ba1119c0-61ce-4a42-9e4c-0ea2f57145eb@github.com>
Message-ID: <7w3okXKFhjzXb1zG6J-pfS1skbQqOsmKnt9Wpxap83o=.1fb9f308-b219-4acb-9b75-8de05c43055d@github.com>

On Wed, 25 Jun 2025 17:08:20 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update majorticks translation
>  - Merge branch '8359761' of github.com:alisenchung/jdk into 8359761
>  - fix colon in chinese security.properties file

Overall looks correct to me, and it seems you addressed all of the suggestions left by other reviewers. I skimmed most of the files for any glaring issues and also spot checked a few to make sure their associated English file had the correct corresponding change.

Left some small comments which should be addressed.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties line 36:

> 34: MSG_Help_mac_install=\  --mac-dmg-content <Pfad zu zus?tzlichem Inhalt>[,<Pfad zu zus?tzlichem Inhalt>...]\n          Nimmt den gesamten referenzierten Inhalt in die DMG-Datei auf.\n          Diese Option kann mehrmals verwendet werden. \n
> 35: MSG_Help_mac_launcher=\  --mac-package-identifier <ID-Zeichenfolge>\n          Eine ID, die die Anwendung f?r macOS eindeutig identifiziert\n          Standardwert ist der Hauptklassenname.\n          Es d?rfen nur alphanumerische Zeichen (A-Z, a-z, 0-9), Bindestriche (-)\n          und Punkte (.) verwendet werden.\n  --mac-package-name <Namenszeichenfolge>\n          Name der Anwendung, wie in der Men?leiste angezeigt\n          Dieser kann vom Anwendungsnamen abweichen.\n          Er darf maximal 15 Zeichen enthalten und muss f?r die Anzeige\n          in der Men?leiste und im Infofenster der Anwendung geeignet sein.\n          Standardwert: Anwendungsname.\n  --mac-package-signing-prefix <Pr?fixzeichenfolge>\n          Beim Signieren des Anwendungspackages wird dieser Wert\n          allen zu signierenden Komponenten ohne vorhandene\n          Package-ID als Pr?fix vorangestellt.\n  --mac-sign\n          Anforderung zum Signieren des Packages oder des vordefinierten\n
 Anwendungsimages\n  --mac-signing-keychain <Schl?sselbundname>\n          Name des Schl?sselbundes f?r die Suche nach der Signaturidentit?t\n          Bei fehlender Angabe werden die Standardschl?sselbunde verwendet.\n  --mac-signing-key-user-name <Teamname>\n          Team- oder Benutzernamensteil der Apple-Signaturidentit?ten. Um direkt zu steuern,\n          welche Signaturidentit?t zum Signieren eines Anwendungsimages oder\n          Installationsprogramms verwendet wird, verwenden Sie --mac-app-image-sign-identity und/oder\n          --mac-installer-sign-identity. Diese Option kann nicht mit\n          --mac-app-image-sign-identity oder --mac-installer-sign-identity kombiniert werden.\n  --mac-app-image-sign-identity <identity>\n          Zum Signieren des Anwendungsimages verwendete Identit?t. Dieser Wert wird\n          direkt an die Option --sign des Tools "codesign" ?bergeben. Diese Option kann nicht\n          mit --mac-signing-key-user-name kombiniert werden.\n  
 --mac-installer-sign-identity <identity>\n          Zum Signieren des Installationsprogramms "pkg" verwendete Identit?t. Dieser Wert wird\n          direkt an die Option --sign des Tools "productbuild" ?bergeben. Diese Option\n          kann nicht mit --mac-signing-key-user-name kombiniert werden.\n  --mac-app-store\n          Gibt an, dass die jpackage-Ausgabe f?r den\n          Mac App Store bestimmt ist.\n  --mac-entitlements <Dateipfad>\n          Pfad zu einer Datei mit Berechtigungen, die beim Signieren\n          von ausf?hrbaren Dateien und Librarys im Bundle verwendet werden sollen.\n  --mac-app-category <Kategoriezeichenfolge>\n          Zeichenfolge f?r das Erstellen von LSApplicationCategoryType in\n          Anwendungs-plist. Standardwert: "utilities".\n
> 36: MSG_Help_linux_install=\  --linux-package-name <Packagename>\n          Name f?r das Linux-Package, Standardwert: Anwendungsname\n  --linux-deb-maintainer <E-Mail-Adresse>\n          Maintainer f?r .deb-Package\n  --linux-menu-group <Men?gruppenname>\n          Men?gruppe, in der diese Anwendung abgelegt wird\n  --linux-package-deps <package-dep-string>\n          Erforderliche Packages oder Funktionen f?r die Anwendung\n  --linux-rpm-license-type <Typzeichenfolge>\n          Typ der Lizenz ("License: <Wert>" der RPM-SPEC-Datei)\n  --linux-app-release <Releasewert>\n          Releasewert der RPM-SPEC-Datei <Name> oder \n          Debian-Revisionswert der DEB-Kontrolldatei\n  --linux-app-category <Kategoriewert>\n          Gruppenwert der RPM-SPEC-Datei <Name> oder \n          Abschnittswert der DEB-Kontrolldatei\n  --linux-shortcut\n          Erstellt eine Verkn?pfung f?r die Anwendung.\n

"package-dep-string" is within "<>" and should not be translated. ja and zh_CN locales remain un-translated as well. I'd like this particular one to be reverted back and we can file an issue with the translation team.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_en.wxl line 1:

> 1: <?xml version="1.0" encoding="utf-8"?>

This change can be reverted, the English file should not be touched anyways during l10n.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959683606
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167643767
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167645253

From achung at openjdk.org  Wed Jun 25 21:28:16 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 25 Jun 2025 21:28:16 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  revert german translation, revert english wxl format change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/67990651..d54f457d

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

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

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

From jlu at openjdk.org  Wed Jun 25 21:43:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 21:43:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <L30V0OupKPnDuj1v0M_paL96VPnJ4FBQpxbR-csL9qw=.c5a4c608-2a73-4002-95ad-7af701fad29e@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959749881

From jlu at openjdk.org  Wed Jun 25 22:55:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Jun 2025 22:55:33 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v2]
In-Reply-To: <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <1H_WgwF6mPWZ6l0Gjwg18qYBm8kS3-XKI2uXpgTqsFM=.73b2285c-23cc-4d9d-bed2-10feda82315f@github.com>
 <n42uuxgae9PBvLNZy8lNWD_HnTnj4pWFbsI1_8q2Wbc=.3a3ff3b3-b385-4ba0-9ece-f179dbac63d4@github.com>
 <SpVZ52poJGvsBGyuVB8B91ZEje1QaAafXfnEovQx0-I=.640d1f5f-8222-402a-b075-dea1ea46bd81@github.com>
 <ij3E2h5HHVXFll_xif0vHx4lrh6_QkTohC0rAZW2dGA=.03b17f7f-14cf-49bb-92c5-7f0033e6ccb7@github.com>
 <WuQvK5zsAIoLmBECTsLi2L1CDnyqyNyHhISc_Fmyel8=.b28647b1-80b6-44cf-bc67-5e9a6a4bb272@github.com>
 <570JPur5CDdEKtLyaTZEthUJePWje6-WK49sZNCBFEs=.058eb1d3-c0f4-48f3-90a4-cd29ad41dccf@github.com>
Message-ID: <9xiUCl6NKMT520fpbnfGriItpYYHh93M9Gn2T5nfEIE=.3e8ab340-855f-47cb-87ba-1d3275a37598@github.com>

On Tue, 24 Jun 2025 14:58:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> However, there is no space required between two Chinese sentences. In English, we usually write "I am here, and you are there." But in Chinese, with the full-width punctuation, it's always "??????????".
>
> Some people like to insert a space between a Chinese character and a Latin letter. I?m not a fan of this style, but I don?t feel strongly about it. However, adding a space between two Chinese characters or between a Chinese character and a full-width punctuation mark is unusual.

As discussed offline, since there are many instances of this, we will file an issue with the translation team and see if they will agree to the suggested changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2167774594

From dnguyen at openjdk.org  Thu Jun 26 00:18:39 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 26 Jun 2025 00:18:39 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <Qjn1b786Q_fqBZXGYAGl3IMk-YzmCrxtqRKk89XCng4=.e49c60eb-2751-41b4-ab25-283c00b3bb4d@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2959999177

From cstein at openjdk.org  Thu Jun 26 05:23:31 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 26 Jun 2025 05:23:31 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <4Yu9Xo_LEoSLn6WwWbZB5GoLk0YroJfIT8B2izB5Y2k=.372e1dfb-bf3f-4ca7-be8c-edf13e87533c@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

German `_de` translations look good to me.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2960590912

From naoto at openjdk.org  Thu Jun 26 16:11:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jun 2025 16:11:35 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <yCfy1s78TO0A4KkM8-Dsfwel3MyFrljHZZfcOY31X6o=.9826e189-d4d2-4166-9634-e35bd79cf55d@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

Looks fine to me. Thanks, Alisen!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2962676541

From aivanov at openjdk.org  Thu Jun 26 17:32:34 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Jun 2025 17:32:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
Message-ID: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>

On Wed, 25 Jun 2025 21:28:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert german translation, revert english wxl format change

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:

> 459: SliderDemo.majorticks=Hauptteilstriche
> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften

@sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).

Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?

Should *Beschriften* rather be *Beschriftung*?

Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?

src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 463:

> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
> 462: SliderDemo.minorticks=Hilfsteilstriche
> 463: SliderDemo.minorticksdescription=Ein Schieberegler mit Haupt- und Hilfsteilstrichen, mit Teilstrichen, in die der Schieberegler einrastet, wobei einige Teilstriche mit einem sichtbaren Label versehen sind

This one is repetitive:
Suggestion:

SliderDemo.minorticksdescription=Ein Schieberegler mit Haupt- und Hilfsteilstrichen, in die der Schieberegler einrastet, wobei einige Teilstriche mit einer sichtbaren Beschriftung versehen sind

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169540017
PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169535281

From cstein at openjdk.org  Thu Jun 26 17:44:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 26 Jun 2025 17:44:34 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
 <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
Message-ID: <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>

On Thu, 26 Jun 2025 17:22:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert german translation, revert english wxl format change
>
> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:
> 
>> 459: SliderDemo.majorticks=Hauptteilstriche
>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
> 
> @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).
> 
> Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?
> 
> Should *Beschriften* rather be *Beschriftung*?
> 
> Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?

You may (re-)use every German verb as a noun: [Substantivierung](https://de.wikipedia.org/wiki/Substantivierung)

> Would Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen be a better translation?

Nein. Sounds too disrupted/distorted in my ears. If you really want to make it longer, it could read like:

_Hilfsteilstriche, an denen der Schieberegler einrastet und denen Beschriftungen angebracht werden k?nnen_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169576244

From achung at openjdk.org  Thu Jun 26 20:56:39 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Jun 2025 20:56:39 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v8]
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25839/files
  - new: https://git.openjdk.org/jdk/pull/25839/files/d54f457d..dcce2a39

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

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

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

From achung at openjdk.org  Thu Jun 26 20:56:40 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Jun 2025 20:56:40 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v7]
In-Reply-To: <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <ukl_ukcO4mp0UmS1YkfdmbsViiqkIWOq0CGhn58I-2A=.da968e7e-c61b-49b0-b3ed-c01c2031f477@github.com>
 <6E-wE5Z32CVZsOTCjwVkJBY_WZWE69KJ1BmYcSRH26U=.90929e1a-7b80-4c8d-85b7-13714803cb9e@github.com>
 <hFn5wmgbm5zMsnPdoOpOohNFpP1Rt1LK5xzezGmNW-g=.22beef9d-e3be-4862-819f-69da291a0c63@github.com>
Message-ID: <SglYkl97hMPTI35H7e9VncJTC3GWAW2mRgU72vGs3eI=.d8f3e462-116e-4530-bc97-bb4cab345fb7@github.com>

On Thu, 26 Jun 2025 17:41:13 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/demo/share/jfc/SwingSet2/resources/swingset_de.properties line 461:
>> 
>>> 459: SliderDemo.majorticks=Hauptteilstriche
>>> 460: SliderDemo.majorticksdescription=Ein Schieberegler mit Hauptteilstrichen
>>> 461: SliderDemo.ticks=Hilfsteilstriche, zum Einrasten und Beschriften
>> 
>> @sormuras Is this the correct German? A follow-up from [previous discussion](https://github.com/openjdk/jdk/pull/25839#discussion_r2162982972).
>> 
>> Both *Einrasten* and *Beschriften* are verbs, aren't they? Why are they capitalised?
>> 
>> Should *Beschriften* rather be *Beschriftung*?
>> 
>> Would *Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen* be a better translation?
>
> You may (re-)use every German verb as a noun: [Substantivierung](https://de.wikipedia.org/wiki/Substantivierung)
> 
>> Would Hilfsteilstriche, Einrasten an Teilstrichen, Beschriftungen be a better translation?
> 
> Nein. Sounds too disrupted/distorted in my ears. If you really want to make it longer, it could read like:
> 
> _Hilfsteilstriche, an denen der Schieberegler einrastet und denen Beschriftungen angebracht werden k?nnen_

Maybe better to leave this one as is and next drop the translation team can take another look

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25839#discussion_r2169956970

From aivanov at openjdk.org  Fri Jun 27 11:57:44 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Jun 2025 11:57:44 GMT
Subject: RFR: 8359761: JDK 25 RDP1 L10n resource files update [v8]
In-Reply-To: <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
 <wde0M3LUuqMdILh7rklStZmGCU3jZKf0ruVujEePt0c=.3601d7c3-7e4c-494c-9599-be3adb908f4e@github.com>
Message-ID: <vWI5H8ceYQIjIidhY4mIYGYza-hAcdeWODbUDEsvWCM=.281ca419-7152-43a9-b2be-8fd5f2e163c8@github.com>

On Thu, 26 Jun 2025 20:56:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/demo/share/jfc/SwingSet2/resources/swingset_de.properties
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25839#pullrequestreview-2966237280

From jan.lahoda at oracle.com  Fri Jun 27 13:29:42 2025
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 27 Jun 2025 15:29:42 +0200
Subject: Use of the kulla-dev mailing list
Message-ID: <74a0661e-1a72-44ec-a993-469f89c59c12@oracle.com>

Hello JShell users and developers,

The "Kulla" project was founded to develop JShell, and bring it into the 
JDK. That happened in JDK 9, almost 8 years ago. Since then JShell has 
been an integral part of the JDK, and the Kulla project exists basically 
only to keep this mailing list.

Given all this, we propose to dissolve and archive the Kulla project. As 
a consequence, this mailing list would no longer work. Moving forward, 
we shall use compiler-dev (compiler-dev at openjdk.org) for JShell-related 
posts, given (a) the close connection between JShell and javac, and (b) 
the relatively low amount of traffic on this list.

Please let me know if there are any concerns with the plan outline 
above. If there are none, we will proceed to dissolve the Kulla project 
and start using the compiler-dev mailing list for JShell.

Thanks for your JShell support!

 ??? Jan


From achung at openjdk.org  Fri Jun 27 16:15:51 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 16:15:51 GMT
Subject: Integrated: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
References: <yFHtJVbU6-KK5KZN8Gq40D5qT8GYsm3gw-EILhejTr4=.49bda9de-d594-4774-a644-d87b6ec6561b@github.com>
Message-ID: <GF5IDxTAhXqzc73VVys13RSJKUc87JeYqSfSPXZjZWM=.997990aa-1178-4323-83b0-de46c0f2b455@github.com>

On Tue, 17 Jun 2025 01:22:31 GMT, Alisen Chung <achung at openjdk.org> wrote:

> This issue is responsible for updating the translations of all the localize(able) resources in the JDK since the previous L10n drop.

This pull request has now been integrated.

Changeset: da7080ff
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da7080fffb2389465dc9afca6d02e9085fe15302
Stats:     1196 lines in 71 files changed: 814 ins; 93 del; 289 mod

8359761: JDK 25 RDP1 L10n resource files update

Reviewed-by: aivanov, almatvee, nbenalla, jlu, dnguyen, cstein, naoto

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

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

From achung at openjdk.org  Fri Jun 27 18:31:40 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 18:31:40 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
Message-ID: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>

8359761: JDK 25 RDP1 L10n resource files update

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

Commit messages:
 - Backport da7080fffb2389465dc9afca6d02e9085fe15302

Changes: https://git.openjdk.org/jdk/pull/26026/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26026&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359761
  Stats: 1196 lines in 71 files changed: 814 ins; 93 del; 289 mod
  Patch: https://git.openjdk.org/jdk/pull/26026.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26026/head:pull/26026

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

From jlu at openjdk.org  Fri Jun 27 18:48:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Jun 2025 18:48:40 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <K1-1d3pNRFgWpkSWz0z37g8bv6FZDptY3FqWn6mA1YM=.b1642fa3-3131-475d-be48-e46ae826b1ca@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967612181

From aivanov at openjdk.org  Fri Jun 27 18:58:42 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Jun 2025 18:58:42 GMT
Subject: [jdk25] RFR: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <kg51-qmlCGiGQD2uT5jUV-tXzjg56nUx10DltgKO0xY=.eec85c62-ad07-4181-bfcb-37b946b625b3@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26026#pullrequestreview-2967634176

From achung at openjdk.org  Fri Jun 27 19:31:01 2025
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 27 Jun 2025 19:31:01 GMT
Subject: [jdk25] Integrated: 8359761: JDK 25 RDP1 L10n resource files update
In-Reply-To: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
References: <Z-0Oad8hly2CCUVUO68zsuIi18AffuFUgomulIw9_H0=.594abd54-1017-4506-a736-d22ac12ad574@github.com>
Message-ID: <Lvees89-ahp6rs1DC7OJnMRzhPaBlrM8HoOj1YDdGq4=.d69d8c1f-63dc-43e3-a8d4-bd98d3bb8670@github.com>

On Fri, 27 Jun 2025 18:27:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> 8359761: JDK 25 RDP1 L10n resource files update

This pull request has now been integrated.

Changeset: 12ffb0c1
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12ffb0c131c5100dc23549b9b7216625bc0dab9e
Stats:     1196 lines in 71 files changed: 814 ins; 93 del; 289 mod

8359761: JDK 25 RDP1 L10n resource files update

Reviewed-by: jlu, aivanov
Backport-of: da7080fffb2389465dc9afca6d02e9085fe15302

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

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

From cstein at openjdk.org  Mon Jun 30 07:31:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 30 Jun 2025 07:31:51 GMT
Subject: RFR: 8358552: EndOfFileException in System.in.read() and IO.readln()
 etc. in JShell
Message-ID: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>

Please review this change to handle an `EndOfFileException` while reading input from a user console in such a way, that no stacktrace is emitted. The handling of the `Ctrl+D` command is left as-is; here the following underlying core-libs should stay in control:

 - `System.in.read()`
 - `System.console().reader().read()`
 - `System.console().readLine()`
 - `System.console().readPassword()`
 - `System.in.readAllBytes()`
 - `IO.readln()`

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

Commit messages:
 - 8358552: EndOfFileException in System.in.read() and IO.readln() etc. in JShell

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

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

From cstein at openjdk.org  Mon Jun 30 07:31:52 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 30 Jun 2025 07:31:52 GMT
Subject: RFR: 8358552: EndOfFileException in System.in.read() and
 IO.readln() etc. in JShell
In-Reply-To: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>
References: <PfXaK5s0zBv0kzlBYPl9HP_oEzdqv8vzQAUMJSHATIg=.cc8c51e4-709d-4da9-a511-4a1a6a6af780@github.com>
Message-ID: <41KLHstELyXrWp7ErJU59UIzTb2MyiKmlf0dr9mUs0U=.0d6ed7ce-9330-4a77-bf03-94515240f530@github.com>

On Tue, 10 Jun 2025 08:29:15 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to handle an `EndOfFileException` while reading input from a user console in such a way, that no stacktrace is emitted. The handling of the `Ctrl+D` command is left as-is; here the following underlying core-libs should stay in control:
> 
>  - `System.in.read()`
>  - `System.console().reader().read()`
>  - `System.console().readLine()`
>  - `System.console().readPassword()`
>  - `System.in.readAllBytes()`
>  - `IO.readln()`

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

> 76:                 "System.console().readPassword()",  " ==> null",
> 77:                 "IO.readln()",                      " ==> \"null\""
> 78:                 // TODO , "System.in.readAllBytes()", " ==> " // ... hangs forever

Manual testing in a JShell session with this change set applied shows the watend behaviour: breaks with Ctrl+C and no exception is printed for Ctrl+D

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25713#discussion_r2174399555