From kevinw at openjdk.org  Wed Jun 11 15:22:42 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Jun 2025 15:22:42 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates equals/hashCode
 contract after deserialization
Message-ID: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>

Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.

The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, they change a class named "immutable).

Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.

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

Commit messages:
 - spelling
 - Exception name
 - whitespace
 - whitespace
 - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

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

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

From kevinw at openjdk.org  Thu Jun 12 08:09:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Jun 2025 08:09:04 GMT
Subject: jmx-dev RFR: 8351413: Remove XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport
Message-ID: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com>

Removal of an obscure historical feature, following on from its deprecation for removal in:

8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

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

Commit messages:
 - 8351413: Remove XML interchange in java.management/javax/management/modelmbean/DescriptorSupport

Changes: https://git.openjdk.org/jdk/pull/25697/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25697&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351413
  Stats: 649 lines in 6 files changed: 0 ins; 644 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25697/head:pull/25697

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

From sroy at openjdk.org  Thu Jun 12 16:07:09 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Thu, 12 Jun 2025 16:07:09 GMT
Subject: jmx-dev RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
Message-ID: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>

JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)

c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)

This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.

Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.

Similarly for c2_globals.hpp &etc.

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

Commit messages:
 - Update c2_globals.hpp
 - c1 header
 - global headers

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

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

From mhaessig at openjdk.org  Thu Jun 12 16:53:30 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 12 Jun 2025 16:53:30 GMT
Subject: jmx-dev RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <SlD-5xgjDNawUTjiEnA3hum1jq3bXCdrOLCVfXFuNwk=.e0bd6eec-5f49-43c7-b152-fd4e9a1cfd6d@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

Thank you for working on this, @suchismith1993! Good to see the includes cleaned up.

This looks good to me, but I nevertheless kicked off some testing on our side. I will let you know how it went when the results are in.

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

PR Review: https://git.openjdk.org/jdk/pull/25773#pullrequestreview-2921960450

From kbarrett at openjdk.org  Fri Jun 13 06:29:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Jun 2025 06:29:28 GMT
Subject: jmx-dev RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <wb2jgX5PIpkRu7SJGj4noJpsgWqtWE80L1binY_S4Yw=.ad836c4d-48f0-4f04-966e-138ab2d2418b@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25773#pullrequestreview-2923554527

From mhaessig at openjdk.org  Fri Jun 13 09:01:36 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 13 Jun 2025 09:01:36 GMT
Subject: jmx-dev RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <7iAduRwCTEhdlLrawIwYXAM4k5l5PRY7090XOYJeheE=.c279c29b-8316-4551-852c-d44bb8fe058a@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

Testing passed. Ship it!

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

Marked as reviewed by mhaessig (Author).

PR Review: https://git.openjdk.org/jdk/pull/25773#pullrequestreview-2923939477

From duke at openjdk.org  Fri Jun 13 09:17:30 2025
From: duke at openjdk.org (duke)
Date: Fri, 13 Jun 2025 09:17:30 GMT
Subject: jmx-dev RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <mMw3eJ099udlNfLFQP0jUmY1BUy2GYsVmXGmTYX1mDc=.ea38f68e-fcc0-48d2-850d-2ad81db0ecc2@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

@suchismith1993 
Your change (at version 993ee2632f0e7be6a6eb40d22a98c4e8d5da29e2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25773#issuecomment-2969667508

From dcubed at openjdk.org  Fri Jun 13 16:14:46 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 13 Jun 2025 16:14:46 GMT
Subject: jmx-dev RFR: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <xVR85dKJNzZ2BtnAYUVBRJNf51OPHxgcGDkIz4Bbw0g=.4cd70809-f018-4524-b31e-0ad4f53741c1@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

(Gotta love it when you typo a lable^H^H^H^H^H label).

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

PR Comment: https://git.openjdk.org/jdk/pull/25773#issuecomment-2970862022

From sroy at openjdk.org  Mon Jun 16 08:33:36 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 16 Jun 2025 08:33:36 GMT
Subject: jmx-dev Integrated: JDK-8348574 : Simplify c1/c2_globals inclusions
In-Reply-To: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
References: <JgBcVpl8EKJnGkaPv_XYNgxMozGngHOazef7s_Aepc0=.2a560ad9-b99d-46f4-ab43-409b405ca650@github.com>
Message-ID: <TqLcquWtZAoKyLQJ23EaSz9Sr6EbH4rayHoAHT_82Po=.333b1007-7d58-4de3-b6bf-88656ed9db40@github.com>

On Thu, 12 Jun 2025 08:32:56 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8348574](https://bugs.openjdk.org/browse/JDK-8348574)
> 
> c1_globals.hpp includes c1_globals_pd.hpp. c1_globals_pd.hpp includes the corresponding CPU_HEADER and OS_HEADER files. All of the c1_globals_<os>.hpp files are essentially identical and basically empty. (They just include globalDefinitions.hpp and macros.hpp, and provide nothing additional.)
> 
> This could be simplified by having c1_globals.hpp do the CPU_HEADER inclusion directly, and remove c1_globals_pd.hpp and all c1_globals_<os>.hpp files.
> 
> Even if there are some non-vacuous c1_globals_<os>.hpp files in the future, c1_globals_pd.hpp seems unwarranted; just add the OS_HEADER include directly in c1_globals.hpp. The c1_globals_pd.hpp files really don't seem worth the extra indirection.
> 
> Similarly for c2_globals.hpp &etc.

This pull request has now been integrated.

Changeset: 79497ef7
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Varada M <varadam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79497ef7f55ef445b31348ae9d3d6dff6d3b6a54
Stats:     366 lines in 13 files changed: 2 ins; 360 del; 4 mod

8348574: Simplify c1/c2_globals inclusions

Reviewed-by: mhaessig, kbarrett

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

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

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: jmx-dev 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 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: jmx-dev 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:18:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Jun 2025 23:18:29 GMT
Subject: jmx-dev 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 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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 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: jmx-dev 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 kevinw at openjdk.org  Wed Jun 18 11:39:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 18 Jun 2025 11:39:04 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
Message-ID: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>

javax.management classes AttributeList, RoleList and UnresolvedRoleList have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.

This feature should be removed, and these classes should never accept the wrong kind of Object.

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

Commit messages:
 - test/jdk/javax/management/generified/ListTypeCheckTest.java

Changes: https://git.openjdk.org/jdk/pull/25856/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359809
  Stats: 257 lines in 5 files changed: 42 ins; 164 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/25856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856

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

From kevinw at openjdk.org  Wed Jun 18 11:39:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 18 Jun 2025 11:39:04 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <lM5XX4Je06UCEnDo84fxvJhq1-DIeOWjLuAnjvCgTeQ=.f645452c-7f2b-403a-a1cf-9acd1b659f8d@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> javax.management classes AttributeList, RoleList and UnresolvedRoleList have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

src/java.management/share/classes/javax/management/relation/RoleList.java line 195:

> 193: 
> 194:         if (role == null) {
> 195:             throw new IllegalArgumentException("Invalid parameter");

Removing the trailing dot from "parameter.", here and new line 247 below, to be in line with the rest.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2154370578

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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 kevinw at openjdk.org  Thu Jun 19 11:17:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 19 Jun 2025 11:17:01 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v2]
In-Reply-To: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
Message-ID: <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>

> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
> 
> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
> 
> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.

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

 - Merge remote-tracking branch 'upstream/master' into 8358624_ImmutableDescriptor_hashcode
 - spelling
 - Exception name
 - whitespace
 - whitespace
 - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25758/files
  - new: https://git.openjdk.org/jdk/pull/25758/files/a94b49ef..6f28e857

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

  Stats: 14540 lines in 274 files changed: 10342 ins; 3094 del; 1104 mod
  Patch: https://git.openjdk.org/jdk/pull/25758.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25758/head:pull/25758

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

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: jmx-dev 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 sspitsyn at openjdk.org  Fri Jun 20 17:08:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Jun 2025 17:08:33 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v2]
In-Reply-To: <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
Message-ID: <xiUjG--xMPf_APiSSqHujEr5Wji7UnaUhtwrbXmbj-Q=.05e40d15-324c-4589-b386-affa62c23786@github.com>

On Thu, 19 Jun 2025 11:17:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8358624_ImmutableDescriptor_hashcode
>  - spelling
>  - Exception name
>  - whitespace
>  - whitespace
>  - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

src/java.management/share/classes/javax/management/ImmutableDescriptor.java line 141:

> 139:             bad = true;
> 140:         if (!bad) {
> 141:             hashCode = -1; // Force recalculation

Nit: Would it make sense to add same comment to the lines: 445, 452,473, 493?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25758#discussion_r2159391491

From sspitsyn at openjdk.org  Fri Jun 20 17:43:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Jun 2025 17:43:29 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

src/java.management/share/classes/javax/management/relation/RoleList.java line 265:

> 263:     @Override
> 264:     public boolean add(Object o) {
> 265:         checkTypeSafe(o);

Q: Is `null` allowed? The same question applies to the `addAll()` if these methods allow null to be present in the collection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2159436534

From kevinw at openjdk.org  Fri Jun 20 18:20:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 20 Jun 2025 18:20:28 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
Message-ID: <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>

On Fri, 20 Jun 2025 17:40:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
>> 
>> This feature should be removed, and these classes should never accept the wrong kind of Object.
>
> src/java.management/share/classes/javax/management/relation/RoleList.java line 265:
> 
>> 263:     @Override
>> 264:     public boolean add(Object o) {
>> 265:         checkTypeSafe(o);
> 
> Q: Is `null` allowed? The same question applies to the `addAll()` if these methods allow null to be present in the collection.

The intent here is not to change behaviour regarding nulls.
Nulls have been permitted, and should stay permitted.
Other object types (that don't cast to Role, in this file) should fail.

The Role related files are quite unusual to use, so expect they are mostly used only by the JDK.
MBean code might more commonly manipulate an AttributeList, and we can still permit nulls in case such code relies on nulls being accepted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2159481021

From cjplummer at openjdk.org  Fri Jun 20 19:33:29 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 20 Jun 2025 19:33:29 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v2]
In-Reply-To: <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
Message-ID: <DG724DU9OBw81AooyU6fLDrTmn--evUG6FPA15YsJaI=.9da20c6c-0ee9-459b-9038-329b2130042a@github.com>

On Thu, 19 Jun 2025 11:17:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8358624_ImmutableDescriptor_hashcode
>  - spelling
>  - Exception name
>  - whitespace
>  - whitespace
>  - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

I'm not much of a serialization expert, so just asking for some clarification here. I assume when de-serialized, the initial hashcode is always 0. Why it is 0 and not by default -1. Seems this would be an issue with any de-serialized type and all would need to explicitly set to -1 as you have done in this case.

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

PR Comment: https://git.openjdk.org/jdk/pull/25758#issuecomment-2992607168

From sspitsyn at openjdk.org  Fri Jun 20 21:00:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Jun 2025 21:00:39 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
 <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>
Message-ID: <RZZGrDkvy2igafbzTSeokAVe9gLqG4pcpjDEteopC2Y=.584e62e6-d4e9-4ab5-9814-1f66184c0892@github.com>

On Fri, 20 Jun 2025 18:18:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/relation/RoleList.java line 265:
>> 
>>> 263:     @Override
>>> 264:     public boolean add(Object o) {
>>> 265:         checkTypeSafe(o);
>> 
>> Q: Is `null` allowed? The same question applies to the `addAll()` if these methods allow null to be present in the collection.
>
> The intent here is not to change behaviour regarding nulls.
> Nulls have been permitted, and should stay permitted.
> Other object types (that don't cast to Role, in this file) should fail.
> 
> The Role related files are quite unusual to use, so expect they are mostly used only by the JDK.
> MBean code might more commonly manipulate an AttributeList, and we can still permit nulls in case such code relies on nulls being accepted.

My question was because there are checks for `null` in this class:

public void add(Role role)
        throws IllegalArgumentException {

        if (role == null) {
            throw new IllegalArgumentException("Invalid parameter");
        }
        checkTypeSafe(role);
        super.add(role);
    }

It is kind of confusing and not clear where `null` is allowed and where it is not.
Should it be more consistent?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2159655977

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: jmx-dev 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 kevinw at openjdk.org  Mon Jun 23 10:13:34 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 23 Jun 2025 10:13:34 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v2]
In-Reply-To: <DG724DU9OBw81AooyU6fLDrTmn--evUG6FPA15YsJaI=.9da20c6c-0ee9-459b-9038-329b2130042a@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
 <DG724DU9OBw81AooyU6fLDrTmn--evUG6FPA15YsJaI=.9da20c6c-0ee9-459b-9038-329b2130042a@github.com>
Message-ID: <jtK-icBxL9RMRGr0vKApJXSgR7hW9BRKj_kFiGrjlFw=.4fcb1531-f30b-468e-8c53-10e8e3334cce@github.com>

On Fri, 20 Jun 2025 19:30:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I'm not much of a serialization expert, so just asking for some clarification here. I assume when de-serialized, the initial hashcode is always 0. Why it is 0 and not by default -1. Seems this would be an issue with any de-serialized type and all would need to explicitly set to -1 as you have done in this case.

As a transient field the hashCode int is not restored by serialization.  But why zero, and not -1 as per the field declaration?

The -1 is set by a constructor in ImmutableDescriptor.

ObjectInputStream:
"Reading an object is analogous to running the constructors of a new object. Memory is allocated for the object and initialized to zero (NULL). No-arg constructors are invoked for the non-serializable classes and then the fields of the serializable classes are restored from the stream starting with the serializable class closest to java.lang.object and finishing with the object's most specific class."

I think that is the explanation: it's all zero'd, and the constructor that would set the -1 doesn't get called.

I see another example (src/java.management/share/classes/javax/management/openmbean/ArrayType.java) where we implement a hashCode member as "private transient Integer  myHashCode = null; "  There we check if that is null, which causes re-calculating of the hashCode on demand after deserialization.  That gets default behaviour of recalculating, but uses a Java object.

This class used a primitive field, I didn't want to change much in this obscure old class.

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

PR Comment: https://git.openjdk.org/jdk/pull/25758#issuecomment-2995805998

From kevinw at openjdk.org  Mon Jun 23 14:40:27 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 23 Jun 2025 14:40:27 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <RZZGrDkvy2igafbzTSeokAVe9gLqG4pcpjDEteopC2Y=.584e62e6-d4e9-4ab5-9814-1f66184c0892@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
 <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>
 <RZZGrDkvy2igafbzTSeokAVe9gLqG4pcpjDEteopC2Y=.584e62e6-d4e9-4ab5-9814-1f66184c0892@github.com>
Message-ID: <LWSmmcWfalhvkPLBhGLy9jSKTOpRJMCWY7bpm0Pr1Vw=.19a18ecc-18c0-4a6e-810e-2981d8c62f37@github.com>

On Fri, 20 Jun 2025 20:56:17 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The intent here is not to change behaviour regarding nulls.
>> Nulls have been permitted, and should stay permitted.
>> Other object types (that don't cast to Role, in this file) should fail.
>> 
>> The Role related files are quite unusual to use, so expect they are mostly used only by the JDK.
>> MBean code might more commonly manipulate an AttributeList, and we can still permit nulls in case such code relies on nulls being accepted.
>
> My question was because there are checks for `null` in this class:
> 
> public void add(Role role)
>         throws IllegalArgumentException {
> 
>         if (role == null) {
>             throw new IllegalArgumentException("Invalid parameter");
>         }
>         checkTypeSafe(role);
>         super.add(role);
>     }
> 
> It is kind of confusing and not clear where `null` is allowed and where it is not.
> Should it be more consistent?

Sorry, to be clearer:

javax/management/AttributeList does accept nulls being added, and should continue to do so because it might be a disruptive change.

RoleList and RoleUnresolvedList do not accept null Role/RoleUnresolved objects: they document that the add() method throws if given a null.

We don't have a need to change either behaviour about accepting nulls.
It should be clear when reading the api docs.  It might be unclear as I am grouping together somewhat unrelated classes here.   There is no reason for a user of AttributeList to expect it behaves the same way as a RoleList.

But we do want to stop accepting alien Objects!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2161794760

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: jmx-dev 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: jmx-dev 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: jmx-dev 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:29 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:29 GMT
Subject: jmx-dev 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: jmx-dev 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:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 23 Jun 2025 16:38:31 GMT
Subject: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 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: jmx-dev 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: jmx-dev 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 sspitsyn at openjdk.org  Wed Jun 25 05:35:28 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 05:35:28 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <LWSmmcWfalhvkPLBhGLy9jSKTOpRJMCWY7bpm0Pr1Vw=.19a18ecc-18c0-4a6e-810e-2981d8c62f37@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
 <LJ8tb5c2ycw3Tpf58943zT8YWUfV0UKNXmT_Z_adsac=.253181f3-9dbf-48bb-bd82-adc9755ff9f4@github.com>
 <nNmiRWgats3p8HoXjUCi1B2uaXEbcfv-Cqoic40sZNM=.4143b1b1-0fb3-47df-9945-47e5fc93d5c3@github.com>
 <RZZGrDkvy2igafbzTSeokAVe9gLqG4pcpjDEteopC2Y=.584e62e6-d4e9-4ab5-9814-1f66184c0892@github.com>
 <LWSmmcWfalhvkPLBhGLy9jSKTOpRJMCWY7bpm0Pr1Vw=.19a18ecc-18c0-4a6e-810e-2981d8c62f37@github.com>
Message-ID: <DocWuLC_rUzGXj2bR4JUE_a6ZRgzGFbSonrJbrwFRrQ=.92521ee8-7a1a-4570-9d7a-ac59d9a8f208@github.com>

On Mon, 23 Jun 2025 14:38:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> My question was because there are checks for `null` in this class:
>> 
>> public void add(Role role)
>>         throws IllegalArgumentException {
>> 
>>         if (role == null) {
>>             throw new IllegalArgumentException("Invalid parameter");
>>         }
>>         checkTypeSafe(role);
>>         super.add(role);
>>     }
>> 
>> It is kind of confusing and not clear where `null` is allowed and where it is not.
>> Should it be more consistent?
>
> Sorry, to be clearer:
> 
> javax/management/AttributeList does accept nulls being added, and should continue to do so because it might be a disruptive change.
> 
> RoleList and RoleUnresolvedList do not accept null Role/RoleUnresolved objects: they document that the add() method throws if given a null.
> 
> We don't have a need to change either behaviour about accepting nulls.
> It should be clear when reading the api docs.  It might be unclear as I am grouping together somewhat unrelated classes here.   There is no reason for a user of AttributeList to expect it behaves the same way as a RoleList.
> 
> But we do want to stop accepting alien Objects!

Okay, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2165819639

From sspitsyn at openjdk.org  Wed Jun 25 05:38:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 25 Jun 2025 05:38:27 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <HIUWIhn9eUZ7YIWvDXaAyPiVymZIGDyZZx8gQSKB9_w=.df4cd850-fe93-431d-bbe3-987631294d8e@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

Joe asked a question in related CSR. I'm also interested to know the answer. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/25856#issuecomment-3003393244

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: jmx-dev 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: jmx-dev 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 kevinw at openjdk.org  Wed Jun 25 17:09:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 17:09:45 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v2]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <xrWAZjmBevHlyEXToiNZIjLouh7cOVvvpKS1XJVCq0I=.2d7f7b87-9210-4fd4-8a64-2805f466216d@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

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

 - fewer checkTypeSafe calls in RoleList and RoleUnresolvedList
 - Merge remote-tracking branch 'upstream/master' into 8359809_AttributeList_stricter
 - test/jdk/javax/management/generified/ListTypeCheckTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/50904f10..afb05434

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

  Stats: 9942 lines in 385 files changed: 3586 ins; 3841 del; 2515 mod
  Patch: https://git.openjdk.org/jdk/pull/25856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856

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

From kevinw at openjdk.org  Wed Jun 25 17:09:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 17:09:45 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <T1j2j84OBTnLTE4qzNqU1WTim3LhBoBN7Abtnf_uYfI=.f48a8cab-f957-415d-9d80-9723f0347c65@github.com>

On Tue, 17 Jun 2025 16:54:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

I will update the CSR to clarify/answer the questions.

I've updated the PR to remove a few checkTypeSafe() calls: they are generally wanted when we add an Object or Collection, but not needed in e.g. an add(Role) method that specifically takes the type that we want.  This is why there are api doc additions for the overridden methods that take Object or Collection, and not for the non-overridden add methods that take a specific type (they don't check the type and throw).

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

PR Comment: https://git.openjdk.org/jdk/pull/25856#issuecomment-3005521578

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: jmx-dev 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 kevinw at openjdk.org  Wed Jun 25 17:28:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 17:28:11 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v3]
In-Reply-To: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
Message-ID: <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>

> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
> 
> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
> 
> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  more comments!

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25758/files
  - new: https://git.openjdk.org/jdk/pull/25758/files/6f28e857..48c46627

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

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

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

From kevinw at openjdk.org  Wed Jun 25 17:28:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 25 Jun 2025 17:28:13 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v2]
In-Reply-To: <xiUjG--xMPf_APiSSqHujEr5Wji7UnaUhtwrbXmbj-Q=.05e40d15-324c-4589-b386-affa62c23786@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <NfRMhB_2QkrVK2HDls3DnfT8ESKAneVF0nHHhJDqVX8=.f4068fc8-185b-4733-8606-0f1de4272c9c@github.com>
 <xiUjG--xMPf_APiSSqHujEr5Wji7UnaUhtwrbXmbj-Q=.05e40d15-324c-4589-b386-affa62c23786@github.com>
Message-ID: <32flfDhWgDdP5fZ23Vb9Dw8x65BwjMMRAHxOZFugcuI=.7f838402-2f11-4e7c-8f9c-6875c95fe435@github.com>

On Fri, 20 Jun 2025 17:05:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8358624_ImmutableDescriptor_hashcode
>>  - spelling
>>  - Exception name
>>  - whitespace
>>  - whitespace
>>  - 8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization
>
> src/java.management/share/classes/javax/management/ImmutableDescriptor.java line 141:
> 
>> 139:             bad = true;
>> 140:         if (!bad) {
>> 141:             hashCode = -1; // Force recalculation
> 
> Nit: Would it make sense to add same comment to the lines: 445, 452,473, 493?

Sure, done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25758#discussion_r2167248301

From cjplummer at openjdk.org  Wed Jun 25 17:48:28 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 25 Jun 2025 17:48:28 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v3]
In-Reply-To: <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
Message-ID: <ymJG6feIs-vy8g5HGodPikDxcIyR3BfjN7V04DSAF6U=.8a6ba3b8-09dd-4893-8340-b20abbb4e54c@github.com>

On Wed, 25 Jun 2025 17:28:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comments!

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25758#pullrequestreview-2959116228

From naoto at openjdk.org  Wed Jun 25 17:53:41 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Jun 2025 17:53:41 GMT
Subject: jmx-dev RFR: 8360554: Use the title from the JSON RFC for the @spec
 tag
Message-ID: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>

A minor doc fix. Avoiding @spec reference clash in the doc build

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

Commit messages:
 - initial commit

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

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

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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 sspitsyn at openjdk.org  Thu Jun 26 05:21:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 26 Jun 2025 05:21:32 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v3]
In-Reply-To: <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
Message-ID: <nMHYVxqyCwBtkqqxQ1blB2VlgiI6xm8fSGNK2RvAdFY=.4eaac677-8623-4e24-97bc-a4c2e3e65b99@github.com>

On Wed, 25 Jun 2025 17:28:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comments!

Marked as reviewed by sspitsyn (Reviewer).

src/java.management/share/classes/javax/management/ImmutableDescriptor.java line 141:

> 139:             bad = true;
> 140:         if (!bad) {
> 141:             hashCode = -1; // Force recalculation

Nit: Better to start the comment with low case. Same for other comments.

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

PR Review: https://git.openjdk.org/jdk/pull/25758#pullrequestreview-2960588030
PR Review Comment: https://git.openjdk.org/jdk/pull/25758#discussion_r2168131452

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: jmx-dev 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 alanb at openjdk.org  Thu Jun 26 05:53:28 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Jun 2025 05:53:28 GMT
Subject: jmx-dev RFR: 8360554: Use the title from the JSON RFC for the
 @spec tag
In-Reply-To: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
References: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
Message-ID: <qfJMhGkrjvkjkJM86-XTcRKBlh0DgAgHIk6XjVWzZN0=.80f00121-f0d7-4229-a0f4-fc26ba5f028b@github.com>

On Wed, 25 Jun 2025 17:49:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A minor doc fix. Avoiding @spec reference clash in the doc build

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25985#pullrequestreview-2960662795

From kevinw at openjdk.org  Thu Jun 26 08:26:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 26 Jun 2025 08:26:32 GMT
Subject: jmx-dev RFR: 8360554: Use the title from the JSON RFC for the
 @spec tag
In-Reply-To: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
References: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
Message-ID: <hDG7lLchkORyyn2Bo-7FFKqPqVRvP47TvcPARI3rUJk=.7b872e21-0936-4232-a396-4dd048b570cc@github.com>

On Wed, 25 Jun 2025 17:49:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A minor doc fix. Avoiding @spec reference clash in the doc build

Sure, looks good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25985#pullrequestreview-2961203385

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: jmx-dev 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 naoto at openjdk.org  Thu Jun 26 16:38:36 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jun 2025 16:38:36 GMT
Subject: jmx-dev RFR: 8360554: Use the title from the JSON RFC for the
 @spec tag
In-Reply-To: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
References: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
Message-ID: <9UIjzlXgNNAJ6owE-VNNSdL-vmDnwDyTlamdbcvEGvw=.739d16f8-565d-4c09-ba7a-f46428d1e6d9@github.com>

On Wed, 25 Jun 2025 17:49:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A minor doc fix. Avoiding @spec reference clash in the doc build

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25985#issuecomment-3009080948

From naoto at openjdk.org  Thu Jun 26 16:38:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 26 Jun 2025 16:38:37 GMT
Subject: jmx-dev Integrated: 8360554: Use the title from the JSON RFC for
 the @spec tag
In-Reply-To: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
References: <wj7B3p32CU4b1vJOO1mDs99R9nx97DdQw2kcnp7bDYQ=.5f76b0f2-6dab-4c44-8e10-a6f72b6505d9@github.com>
Message-ID: <V2Xc0v7pxJtI4CzrsbPVvwhN_DQtQXSA7uCWraaHSys=.4331129b-f35b-43c8-ac75-3189990100f9@github.com>

On Wed, 25 Jun 2025 17:49:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A minor doc fix. Avoiding @spec reference clash in the doc build

This pull request has now been integrated.

Changeset: 83fe688d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83fe688d809ca783f8ebf6528a1cf4540d698fb1
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8360554: Use the title from the JSON RFC for the @spec tag

Reviewed-by: alanb, kevinw

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

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

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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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: jmx-dev 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 kevinw at openjdk.org  Fri Jun 27 15:02:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 15:02:33 GMT
Subject: jmx-dev RFR: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization [v3]
In-Reply-To: <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
 <iAyNybL_UlGIFVjn6jfh4ghgTn-WiV6E1bcERv5RWj8=.daba120e-c3e0-4eec-a1c3-0caa0b910770@github.com>
Message-ID: <aUEon_i5t5cO7-K_tvxvXT-MtYSLb5pJFi8vsDWyNag=.76619804-baa7-4275-80f0-2c8f2695dd00@github.com>

On Wed, 25 Jun 2025 17:28:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
>> 
>> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
>> 
>> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comments!

Thanks Serguei and Chris for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/25758#issuecomment-3013329005

From kevinw at openjdk.org  Fri Jun 27 15:02:34 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 27 Jun 2025 15:02:34 GMT
Subject: jmx-dev Integrated: 8358624: ImmutableDescriptor violates
 equals/hashCode contract after deserialization
In-Reply-To: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
References: <reyKSlJmZYqazfnPxUCK55oTUyXUIwt1B-eBYWDtpf8=.5b809f11-99a5-4817-815d-fd432d3d6fc6@github.com>
Message-ID: <YMKt8x0ieUxhOUPtYpmhHUBT_OkGFErDidScLHVYMQ0=.fd20145e-aa95-4418-b2fd-c25f149b4545@github.com>

On Wed, 11 Jun 2025 15:08:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hashcode needs to be reset to -1 to force its recalculation on next call, after deserialization.
> 
> The change in the readResolve() method is the fix for this problem.  While here I added similar lines in other methods that may update fields (although these are noted as not supported, as they change a class supposedly "immutable").
> 
> Added a test.  There is a test for serialization for this class, but I found it clearer to add the test for this specific recently discovered issue in its own test file.

This pull request has now been integrated.

Changeset: 12196baf
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12196baf6700d00c244747cfa22767e532a4a963
Stats:     82 lines in 2 files changed: 82 ins; 0 del; 0 mod

8358624: ImmutableDescriptor violates equals/hashCode contract after deserialization

Reviewed-by: cjplummer, sspitsyn

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

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

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: jmx-dev 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 kevinw at openjdk.org  Mon Jun 30 13:08:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jun 2025 13:08:28 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v3]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <QUnVLEixD1wlX-Fe5XBgzNnUbUcXKMWb8DlDvkNae0U=.49f64722-ef86-4a5f-b8c9-d2392983e5b0@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

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

 - (C)
 - Merge remote-tracking branch 'upstream/master' into 8359809_AttributeList_stricter
 - fewer checkTypeSafe calls in RoleList and RoleUnresolvedList
 - Merge remote-tracking branch 'upstream/master' into 8359809_AttributeList_stricter
 - test/jdk/javax/management/generified/ListTypeCheckTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/afb05434..ab4fef2f

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

  Stats: 7783 lines in 366 files changed: 3782 ins; 2576 del; 1425 mod
  Patch: https://git.openjdk.org/jdk/pull/25856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856

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

From kevinw at openjdk.org  Mon Jun 30 17:31:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 30 Jun 2025 17:31:53 GMT
Subject: jmx-dev RFR: 8359809: AttributeList,
 RoleList and UnresolvedRoleList should never accept other types of
 Object [v4]
In-Reply-To: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
References: <rJ59fPHaSt-Ho-ngRMbiQ8Ch05I0HzswAQlNe9WX5T4=.8e95ff4a-1a1b-487a-a20a-a5047c9f8693@github.com>
Message-ID: <HqsWHEsDJ8gsdk92cv7FIIiiR6X56c3vUpOazz8IoLs=.2e9b6edd-d5a6-4bad-8a40-bfd65efb77b3@github.com>

> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called.
> 
> This feature should be removed, and these classes should never accept the wrong kind of Object.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Test update, over listIterator and iterator.set()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25856/files
  - new: https://git.openjdk.org/jdk/pull/25856/files/ab4fef2f..8b36d3e5

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

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

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