From jlu at openjdk.org  Tue Jun  3 16:16:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 16:16:08 GMT
Subject: <i18n dev> Integrated: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <kqCsa1NzrqdMmP8-vK1PxG7qjFoG5BUL9F4Tr63W1L0=.e6514553-b10b-4330-86a6-4fee1e01fe39@github.com>

On Thu, 29 May 2025 21:59:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

This pull request has now been integrated.

Changeset: 04c15466
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04c15466f68f1208084ee6e5f2322ace707d0446
Stats:     63 lines in 21 files changed: 0 ins; 5 del; 58 mod

8358095: Cleanup tests with explicit locale provider set to only CLDR

Reviewed-by: bpb, naoto

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

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

From jlu at openjdk.org  Tue Jun  3 16:16:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 16:16:07 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR [v3]
In-Reply-To: <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
Message-ID: <qd-gz4QPAoYviH03C5JXOPq1euH8XlEwfh49I4SzVbI=.683fee1a-8dc9-487b-86b0-e11b51f7942c@github.com>

On Fri, 30 May 2025 17:02:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-add testCompat to Bug8167143.java

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25532#issuecomment-2936166046

From jlu at openjdk.org  Tue Jun  3 16:53:27 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 16:53:27 GMT
Subject: <i18n dev> RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java
Message-ID: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>

Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Tue Jun  3 17:19:27 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 17:19:27 GMT
Subject: <i18n dev> RFR: 8358449: Locale.getISOCountries does not specify
 the returned set is unmodifiable
Message-ID: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>

Please review this trivial doc correction to `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent that the returned Set is unmodifiable. Associated CSR filed.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Tue Jun  3 17:52:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 17:52:13 GMT
Subject: <i18n dev> RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java [v2]
In-Reply-To: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
Message-ID: <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>

> Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review - var rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25621/files
  - new: https://git.openjdk.org/jdk/pull/25621/files/4d587501..a7ce5621

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

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

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

From naoto at openjdk.org  Tue Jun  3 17:52:14 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 17:52:14 GMT
Subject: <i18n dev> RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java [v2]
In-Reply-To: <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
 <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
Message-ID: <7WYQ5-OG0eL4GnmKGQCUnYTXwUmTuCq-VungHRLISak=.c0125bf7-8844-4018-86b3-05c67099ff12@github.com>

On Tue, 3 Jun 2025 17:46:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - var rename

Looks good. Thanks for the repurposing the provider

test/jdk/java/util/TimeZone/Bug8167143.java line 239:

> 237:      */
> 238:     private static void testImplicitFallbackLocales() {
> 239:         LocaleProviderAdapter jre = LocaleProviderAdapter.forType(Type.FALLBACK);

Nit: maybe `jre` can be renamed too

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

PR Review: https://git.openjdk.org/jdk/pull/25621#pullrequestreview-2893474483
PR Review Comment: https://git.openjdk.org/jdk/pull/25621#discussion_r2124509694

From jlu at openjdk.org  Tue Jun  3 17:52:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 17:52:15 GMT
Subject: <i18n dev> RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java [v2]
In-Reply-To: <7WYQ5-OG0eL4GnmKGQCUnYTXwUmTuCq-VungHRLISak=.c0125bf7-8844-4018-86b3-05c67099ff12@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
 <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
 <7WYQ5-OG0eL4GnmKGQCUnYTXwUmTuCq-VungHRLISak=.c0125bf7-8844-4018-86b3-05c67099ff12@github.com>
Message-ID: <knMZNXYwAt3J4bsuMQx3bgzA-WQ40dAy-XYcFJMGXeE=.bf72bb81-de05-40b8-9b91-586937cbedc7@github.com>

On Tue, 3 Jun 2025 17:40:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review - var rename
>
> test/jdk/java/util/TimeZone/Bug8167143.java line 239:
> 
>> 237:      */
>> 238:     private static void testImplicitFallbackLocales() {
>> 239:         LocaleProviderAdapter jre = LocaleProviderAdapter.forType(Type.FALLBACK);
> 
> Nit: maybe `jre` can be renamed too

Definitely; updated in https://github.com/openjdk/jdk/pull/25621/commits/a7ce562157a12dd971e492eab29a669b2a960cf2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25621#discussion_r2124520913

From naoto at openjdk.org  Tue Jun  3 17:52:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 17:52:55 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v3]
In-Reply-To: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>
Message-ID: <gah_JMPE3xHcudSsDq_iqqxmTfi3edTCv8NCbKznr1M=.67bfc258-b96f-4d60-b2f7-cda514b11b68@github.com>

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

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into utf8-minor-cleanup
>  - Revert changes in RotFontBoundsTest.java
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java
>  - Replace uncessary unicode characters with ASCII in instructions, and fix typo
>  - Seems like typos in the comments
>  - Fix unicode sequences in comments (previously missed)

> @naotoj Are you happy with the other changes?

Yes. Thank you for the cleanup!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2893481166

From ihse at openjdk.org  Tue Jun  3 17:52:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 17:52:55 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v3]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <9mEkfsOwQAc6LbxKWQHEMF4GbH_icsLrA_JPWDcIAck=.ec8f6cb8-efa5-4d6f-aadc-c1264ee1dd1a@github.com>

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

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

 - Merge branch 'master' into utf8-minor-cleanup
 - Revert changes in RotFontBoundsTest.java
 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/7184e685..c3027c1a

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

  Stats: 125596 lines in 1865 files changed: 71361 ins; 38692 del; 15543 mod
  Patch: https://git.openjdk.org/jdk/pull/25228.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25228/head:pull/25228

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

From ihse at openjdk.org  Tue Jun  3 17:52:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Jun 2025 17:52:57 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <DsuF98gTV85TRV5ofvmvH_-7fKmRNk28rI3RJV4e6Gk=.bc6bd102-147c-497e-9734-1bf6863060df@github.com>

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

@naotoj Are you happy with the other changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/25228#issuecomment-2936435086

From naoto at openjdk.org  Tue Jun  3 18:00:39 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 18:00:39 GMT
Subject: <i18n dev> RFR: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java [v2]
In-Reply-To: <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
 <oQZZaMDXs3KiFup1B7eUfcDTfj7q8fDnMHDmeEPiwqk=.66d196db-31f7-45f6-88c8-c81847b5f1aa@github.com>
Message-ID: <0EuzPGH-Cxvz8udOUyH6EN6d3lfcpYN6I0YIN60K1ag=.0675c197-3ce1-427d-bebc-351748b9d059@github.com>

On Tue, 3 Jun 2025 17:52:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - var rename

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25621#pullrequestreview-2893527656

From naoto at openjdk.org  Tue Jun  3 18:20:17 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Jun 2025 18:20:17 GMT
Subject: <i18n dev> RFR: 8358449: Locale.getISOCountries does not
 specify the returned set is unmodifiable
In-Reply-To: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
References: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
Message-ID: <cVkPkkjWhwsaRbmeF41pfsdUjwcqTPjo2OoFKYQYyxw=.7172c8ee-9c14-41dd-ac78-5984ee4da621@github.com>

On Tue, 3 Jun 2025 17:13:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial doc correction to `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent that the returned Set is unmodifiable. Associated CSR filed.

Looks good. Reviewed the CSR too, but not sure it would make it for 25 though, as the RDP1 starts the day after tomorrow

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25622#pullrequestreview-2893593915

From jlu at openjdk.org  Tue Jun  3 18:31:16 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Jun 2025 18:31:16 GMT
Subject: <i18n dev> RFR: 8358449: Locale.getISOCountries does not
 specify the returned set is unmodifiable
In-Reply-To: <cVkPkkjWhwsaRbmeF41pfsdUjwcqTPjo2OoFKYQYyxw=.7172c8ee-9c14-41dd-ac78-5984ee4da621@github.com>
References: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
 <cVkPkkjWhwsaRbmeF41pfsdUjwcqTPjo2OoFKYQYyxw=.7172c8ee-9c14-41dd-ac78-5984ee4da621@github.com>
Message-ID: <wqhPlOkR9PzDO2HBWSH91W0tB2B4w-cUp4iv6323pJQ=.fe75a69b-3ab7-4377-925e-8cbf59fc3663@github.com>

On Tue, 3 Jun 2025 18:17:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this trivial doc correction to `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent that the returned Set is unmodifiable. Associated CSR filed.
>
> Looks good. Reviewed the CSR too, but not sure it would make it for 25 though, as the RDP1 starts the day after tomorrow

@naotoj Thanks! I have no issues with deferring if needed, but IIUC I think this change would be fine to make into JDK25 RDP1 since it is a doc-only change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25622#issuecomment-2936646996

From ihse at openjdk.org  Wed Jun  4 08:14:23 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 4 Jun 2025 08:14:23 GMT
Subject: <i18n dev> Integrated: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <At8VnpzuhZYQNUNMKjqDDQJWpn-95O-PP01qGcpOB20=.8371e2ec-5f36-4a13-b566-6482ac2b6667@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

This pull request has now been integrated.

Changeset: edf92721
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/edf92721c2db4cfba091cf4901af603db8486951
Stats:     15 lines in 13 files changed: 0 ins; 0 del; 15 mod

8356977: UTF-8 cleanups

Reviewed-by: naoto, prr

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

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

From jlu at openjdk.org  Wed Jun  4 16:42:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Jun 2025 16:42:55 GMT
Subject: <i18n dev> Integrated: 8358449: Locale.getISOCountries does not
 specify the returned set is unmodifiable
In-Reply-To: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
References: <9Si_Ruzf7n7eVEpEyk1nDssH9q9661mOzNES7OCyELI=.515bdbe0-17fd-4c54-b0e8-4564119274e4@github.com>
Message-ID: <hp1OPc7rGcjB5eaHX30xlkxZEP7wT01FRZTZBsq_VAw=.a8ddab4f-db13-4125-867a-7d33549271b5@github.com>

On Tue, 3 Jun 2025 17:13:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial doc correction to `Locale.getISOCountries(Locale.IsoCountryCode type)` which makes it apparent that the returned Set is unmodifiable. Associated CSR filed.

This pull request has now been integrated.

Changeset: 8a79ac88
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a79ac88639c35a6938f82a391c4b5d77e6eda32
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358449: Locale.getISOCountries does not specify the returned set is unmodifiable

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Wed Jun  4 18:48:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Jun 2025 18:48:53 GMT
Subject: <i18n dev> Integrated: 8358170: Repurpose testCompat in
 test/jdk/java/util/TimeZone/Bug8167143.java
In-Reply-To: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
References: <HrmmeikYwNOcksOC0w_FA77nNhHkdcXWjOIx6cKQWC4=.1d5a6edb-9b7c-4b03-97ce-3c90bc962964@github.com>
Message-ID: <BM4BXCjN9lpVOZ-MJX3XOgQ424cv_wnEKlIIfqEh3YQ=.a63effa7-be28-46f0-8d62-ce7c92f146fc@github.com>

On Tue, 3 Jun 2025 16:47:20 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which modifies the test/jdk/java/util/TimeZone/Bug8167143.java "testCompat" case to be repurposed to check the implicit locales for the FALLBACK BreakIterator and Collator providers. (FALLBACK is the primary provider in those cases.) Since the method is corrected, it can be re-added as a test case. This change stems from discussion in https://git.openjdk.org/jdk/pull/25532.

This pull request has now been integrated.

Changeset: 8f821175
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f821175cc4484d651151818cc518ef608ebcc83
Stats:     39 lines in 1 file changed: 2 ins; 20 del; 17 mod

8358170: Repurpose testCompat in test/jdk/java/util/TimeZone/Bug8167143.java

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Wed Jun  4 21:26:04 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 4 Jun 2025 21:26:04 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale
Message-ID: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>

Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.

Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.

Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).

Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Thu Jun  5 00:20:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Jun 2025 00:20:49 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <ozQnpoa8ilbhpOap8qfjG0IhCu2GOX5DYE342PTSMe8=.56bb67d2-f21d-4617-9204-60f0914ad499@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

Looks correct. Note we have a separate effort #25040 to avoid anonymous supplier classes, don't know if @minborg wishes locale to migrate to that one directly or remain on the more high-level SV.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25646#pullrequestreview-2898526691

From naoto at openjdk.org  Thu Jun  5 01:44:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 01:44:56 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <HI4ELhcHNrZgg7rBbIQXzzvU3UjbiVp5xoYBYcJpofw=.9acdbaf6-52a2-4939-8aff-15b1b1aed792@github.com>

On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

Looks like this PR did not send out the email in the first place, I am leaving a comment to kick the bot

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

PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2942422941

From vyazici at openjdk.org  Thu Jun  5 06:17:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 06:17:53 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <RQJAF7lmALTUQcXhOfsiwP-IgTSGcvPSIKWQd3nI49w=.b4b7eb8d-6f4d-445b-bf3e-de66ee808c53@github.com>

On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

@naotoj, shall we add this note as a comment to places where `-utf8` is added?

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

PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2942906463

From aturbanov at openjdk.org  Thu Jun  5 08:39:52 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 08:39:52 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <l9FKU1UhkZJT5ar0UT2s4SbS4rbwmnJ-40vG8NMqsVc=.414b38ee-14c4-4f24-81e7-4a7e029d3021@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

src/java.base/share/classes/java/util/Locale.java line 2348:

> 2346:     private static volatile Locale defaultFormatLocale;
> 2347: 
> 2348:     private transient final Supplier<String> languageTag =

let's use blessed modifiers order
Suggestion:

    private final transient Supplier<String> languageTag =

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2128278908

From pminborg at openjdk.org  Thu Jun  5 10:57:50 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jun 2025 10:57:50 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <ozQnpoa8ilbhpOap8qfjG0IhCu2GOX5DYE342PTSMe8=.56bb67d2-f21d-4617-9204-60f0914ad499@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <ozQnpoa8ilbhpOap8qfjG0IhCu2GOX5DYE342PTSMe8=.56bb67d2-f21d-4617-9204-60f0914ad499@github.com>
Message-ID: <vaojNywC8FuhQeD-YIIuzIMbflVwbf81SsTn0SdZyNk=.3aa9424d-146e-4378-a699-7a5415fb7096@github.com>

On Thu, 5 Jun 2025 00:18:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> Looks correct. Note we have a separate effort #25040 to avoid anonymous supplier classes, don't know if @minborg wishes locale to migrate to that one directly or remain on the more high-level SV.

Looks good! As @liach mentioned, there is an even better way coming, but I think it's good to do this update anyway. Here is a similar one that I am working on: https://github.com/openjdk/jdk/pull/25630

So, once we have stable field updaters, it will be almost trivial to update the code in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25646#issuecomment-2943716752

From duke at openjdk.org  Thu Jun  5 11:52:51 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 5 Jun 2025 11:52:51 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <iAFbT1HUh2ZRo1jPev8CYqOqlPqjuQYBV_ygHiwLbnw=.319bfb7b-5238-4f55-a356-100ac3d7a5e1@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

src/java.base/share/classes/java/util/Locale.java line 1269:

> 1267:     public static String[] getISOCountries() {
> 1268:         String[] countries = ISO_3166_1_ALPHA2.get();
> 1269:         return Arrays.copyOf(countries, countries.length);

what about `return ISO_3166_1_ALPHA2.get().clone();`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2128662123

From duke at openjdk.org  Thu Jun  5 11:57:52 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 5 Jun 2025 11:57:52 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <DpPjrOn2LEjt7l1xS0feNt3HiRtfMxtIm3AkdnuA55I=.015fc545-2703-4c44-bd01-d3689d6c94b6@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

src/java.base/share/classes/java/util/Locale.java line 2578:

> 2576:                     return Set.of(LocaleISOData.ISO3166_3);
> 2577:                 }
> 2578:             });

What about moving these four stable suppliers and `getISO2Table` to LocaleISOData to shrink size of Locale.java?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2128672698

From erikj at openjdk.org  Thu Jun  5 12:55:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 5 Jun 2025 12:55:53 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <yL5CuAs0Jf9FdyVFsfyUlZ1jXs7c-SG0N27bLHsZ-Yg=.19385987-17f0-4557-817e-8ba70f4ad1ca@github.com>

On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2900205154

From pminborg at openjdk.org  Thu Jun  5 13:11:03 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 5 Jun 2025 13:11:03 GMT
Subject: <i18n dev> RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
Message-ID: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>

This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
 
 
This PR passes tier1, tier2, and tier3 on multiple platforms.

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

Commit messages:
 - Break out logic in separate methods
 - Revoke the use of immutable collections
 - Fix concurrency issues

Changes: https://git.openjdk.org/jdk/pull/25630/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358520
  Stats: 138 lines in 3 files changed: 51 ins; 73 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25630/head:pull/25630

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

From naoto at openjdk.org  Thu Jun  5 18:30:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 18:30:40 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>

> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  java.base/Gensrc.gmk comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25648/files
  - new: https://git.openjdk.org/jdk/pull/25648/files/a5b1c576..5f87c71e

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

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

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

From naoto at openjdk.org  Thu Jun  5 18:30:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 18:30:40 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <HI4ELhcHNrZgg7rBbIQXzzvU3UjbiVp5xoYBYcJpofw=.9acdbaf6-52a2-4939-8aff-15b1b1aed792@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <HI4ELhcHNrZgg7rBbIQXzzvU3UjbiVp5xoYBYcJpofw=.9acdbaf6-52a2-4939-8aff-15b1b1aed792@github.com>
Message-ID: <Y8UxzwkN512bgnQVMyaOMYgjfCQ6mSHESmnVmIBVj7M=.0a746085-fe51-430a-a14c-7bac09303869@github.com>

On Thu, 5 Jun 2025 01:42:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)
>
> Looks like this PR did not send out the email in the first place, I am leaving a comment to kick the bot

> @naotoj, shall we add this note as a comment to places where `-utf8` is added?

Good point. Added.

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

PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2945607754

From jlu at openjdk.org  Thu Jun  5 18:37:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Jun 2025 18:37:51 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <iAFbT1HUh2ZRo1jPev8CYqOqlPqjuQYBV_ygHiwLbnw=.319bfb7b-5238-4f55-a356-100ac3d7a5e1@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <iAFbT1HUh2ZRo1jPev8CYqOqlPqjuQYBV_ygHiwLbnw=.319bfb7b-5238-4f55-a356-100ac3d7a5e1@github.com>
Message-ID: <EnQWlIt1AVWKfSx9hm64Mdl4x8n3NwpAypP1-AjhR3s=.bf69ae0e-fcc8-435b-9830-4e75155ad9ef@github.com>

On Thu, 5 Jun 2025 11:50:01 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> src/java.base/share/classes/java/util/Locale.java line 1269:
> 
>> 1267:     public static String[] getISOCountries() {
>> 1268:         String[] countries = ISO_3166_1_ALPHA2.get();
>> 1269:         return Arrays.copyOf(countries, countries.length);
> 
> what about `return ISO_3166_1_ALPHA2.get().clone();`

`clone` is more concise, but I think I prefer the explicitness of `copyOf` here.

> src/java.base/share/classes/java/util/Locale.java line 2578:
> 
>> 2576:                     return Set.of(LocaleISOData.ISO3166_3);
>> 2577:                 }
>> 2578:             });
> 
> What about moving these four stable suppliers and `getISO2Table` to LocaleISOData to shrink size of Locale.java?

I like this suggestion, we can also move `getISO3Code` in addition to those you mentioned, and have all ISO resources and methods come from LocaleISOData. @naotoj, would you be in favor of this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2129762095
PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2129762038

From naoto at openjdk.org  Thu Jun  5 18:37:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 18:37:52 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale
In-Reply-To: <EnQWlIt1AVWKfSx9hm64Mdl4x8n3NwpAypP1-AjhR3s=.bf69ae0e-fcc8-435b-9830-4e75155ad9ef@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <iAFbT1HUh2ZRo1jPev8CYqOqlPqjuQYBV_ygHiwLbnw=.319bfb7b-5238-4f55-a356-100ac3d7a5e1@github.com>
 <EnQWlIt1AVWKfSx9hm64Mdl4x8n3NwpAypP1-AjhR3s=.bf69ae0e-fcc8-435b-9830-4e75155ad9ef@github.com>
Message-ID: <jZ6bNIBSNkE7s1GHmJ8wat7XdZzP7g5Enx5fLUiayhs=.0eed7199-7282-4806-8741-29a39756df09@github.com>

On Thu, 5 Jun 2025 18:32:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 2578:
>> 
>>> 2576:                     return Set.of(LocaleISOData.ISO3166_3);
>>> 2577:                 }
>>> 2578:             });
>> 
>> What about moving these four stable suppliers and `getISO2Table` to LocaleISOData to shrink size of Locale.java?
>
> I like this suggestion, we can also move `getISO3Code` in addition to those you mentioned, and have all ISO resources and methods come from LocaleISOData. @naotoj, would you be in favor of this?

I agree, that would be more straightforward. Thanks for the suggestion!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2129770483

From naoto at openjdk.org  Thu Jun  5 18:57:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 18:57:50 GMT
Subject: <i18n dev> RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <FLTgBhIXBlLYu3dsr6jL9AILgfvcgXEPzvFAQC4x3t0=.df00f72f-19c4-4979-9b44-df7f2cd57f23@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Looks good and clean. Thanks for the refactoring, Per!

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25630#pullrequestreview-2901743240

From jlu at openjdk.org  Thu Jun  5 20:29:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Jun 2025 20:29:48 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25646/files
  - new: https://git.openjdk.org/jdk/pull/25646/files/b679594c..e6f3d0de

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

  Stats: 155 lines in 2 files changed: 78 ins; 63 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25646/head:pull/25646

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

From jlu at openjdk.org  Thu Jun  5 20:33:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Jun 2025 20:33:50 GMT
Subject: <i18n dev> RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <4NHONywQ86qHsZZDzrOLISzRXv3y4zlfaD2Ug3-GgRM=.99200218-f65a-4a51-8714-a22201cd1937@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Should we consider converting `lookup` in ParallelListResourceBundle.java to be a stable supplier of the CHM as well? Then separating the creation of the map from the insertion of parallel data.

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

PR Comment: https://git.openjdk.org/jdk/pull/25630#issuecomment-2946104521

From naoto at openjdk.org  Thu Jun  5 23:36:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Jun 2025 23:36:55 GMT
Subject: <i18n dev> RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <QG1Di4modF9QI3eRHf9srYM0Q--2EbsVmgkOnRvVm78=.596e153b-74d9-4de8-9417-0dd966c8b945@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

I am thinking about removing javatime supplementary logic altogether, including ParallelListResourceBundle. Might be good to wait for it

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

PR Comment: https://git.openjdk.org/jdk/pull/25630#issuecomment-2946933327

From jlu at openjdk.org  Thu Jun  5 23:42:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 5 Jun 2025 23:42:50 GMT
Subject: <i18n dev> RFR: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <rPykN0FzHb7YxYEupCB-3kHg6dsognSwGNe_pKr3hOg=.b5436b23-c613-42ce-bec6-3bf02c80aaa9@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25630#pullrequestreview-2903045850

From vyazici at openjdk.org  Fri Jun  6 07:04:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:04:00 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
Message-ID: <rPnVSddeu404FxfDv58ka1gnXqAtklhkF94HHHjcZwg=.7b4bae4d-25a8-411f-8b5d-34e307dbd99d@github.com>

On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.base/Gensrc.gmk comment

Verified that
1. `TOOL_CLDRCONVERTER` points to `CLDRConverter`
2. `CLDRConverter` indeed accepts `-utf8`
3. `make/modules/java.base/Gensrc.gmk` and `make/modules/jdk.localedata/Gensrc.gmk` are the only two places where `CLDRConverter` is invoked

make/modules/jdk.localedata/Gensrc.gmk line 49:

> 47: 	    -o $(GENSRC_DIR) \
> 48: 	    -tzdatadir $(TZ_DATA_DIR) \
> 49: 	    -utf8)

@naotoj, I assume you did not add the comment to this change intentionally.

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

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2903974963
PR Review Comment: https://git.openjdk.org/jdk/pull/25648#discussion_r2131625005

From erikj at openjdk.org  Fri Jun  6 08:51:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 6 Jun 2025 08:51:51 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
Message-ID: <rY_BPR5kNLmgWgffDnAE3aLdgvcHwq4f4QqB7bfh5xI=.e84adb3e-a9ad-4698-bbd2-e92a50889b76@github.com>

On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.base/Gensrc.gmk comment

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25648#pullrequestreview-2904257875

From naoto at openjdk.org  Fri Jun  6 15:18:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jun 2025 15:18:51 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <rPnVSddeu404FxfDv58ka1gnXqAtklhkF94HHHjcZwg=.7b4bae4d-25a8-411f-8b5d-34e307dbd99d@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
 <rPnVSddeu404FxfDv58ka1gnXqAtklhkF94HHHjcZwg=.7b4bae4d-25a8-411f-8b5d-34e307dbd99d@github.com>
Message-ID: <VWLCHwmBs2pARXfoUO1Fdeg7rkjC1H2aWFBm-uxEtD4=.38c4e650-ab9c-4421-8c4f-851c9ca6f621@github.com>

On Fri, 6 Jun 2025 06:57:20 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   java.base/Gensrc.gmk comment
>
> make/modules/jdk.localedata/Gensrc.gmk line 49:
> 
>> 47: 	    -o $(GENSRC_DIR) \
>> 48: 	    -tzdatadir $(TZ_DATA_DIR) \
>> 49: 	    -utf8)
> 
> @naotoj, I assume you did not add the comment to this change intentionally.

Yes, that was intentional. It seems apparent that `jdk.localedata` contains resources in non-Latin1 characters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25648#discussion_r2132387343

From naoto at openjdk.org  Fri Jun  6 15:29:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 6 Jun 2025 15:29:53 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
Message-ID: <ZenrQ9LYHfavgv7CKqDJB4TbHlEOJP1u0VXpLD1SZyo=.6f748062-2257-4839-9f48-d6ee1dfb9519@github.com>

On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25646#pullrequestreview-2905273821

From duke at openjdk.org  Sat Jun  7 17:38:52 2025
From: duke at openjdk.org (Johannes Graham)
Date: Sat, 7 Jun 2025 17:38:52 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
Message-ID: <nXLruLQd1Zzx4tlLaTbi6VhM9epxWMyRzGo0dTv17Rc=.d239e5e9-80db-4d3a-9cb4-0adbceb97a58@github.com>

On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag

src/java.base/share/classes/java/util/Locale.java line 1282:

> 1280:     public static Set<String> getISOCountries(IsoCountryCode type) {
> 1281:         Objects.requireNonNull(type);
> 1282:         return switch (type) {

The body of this method could also be moved to a method in `LocaleISOData`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2134036165

From pminborg at openjdk.org  Mon Jun  9 07:03:55 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 9 Jun 2025 07:03:55 GMT
Subject: <i18n dev> Integrated: 8358520: Improve lazy computation in
 BreakIteratorResourceBundle and related classes
In-Reply-To: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
References: <vAv6T-N9ehExoOxncXiljZjGHB3Ok7OIG5hKk7Gcneo=.31eea612-5ef3-4bd9-938f-bf37aa37e317@github.com>
Message-ID: <glahQKpb6QQYyrFfPUKSO35XeJG87ACpx7stwazvdU8=.3f49a8d5-85f3-454a-a49c-590aa1749a88@github.com>

On Tue, 3 Jun 2025 20:14:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to simplify lazy computation related to resource bundles. Previously, some objects were computed lazily using a double-checked locking algorithm. StableValues offers a more robust and succinct solution. 
>  
>  
> This PR passes tier1, tier2, and tier3 on multiple platforms.

This pull request has now been integrated.

Changeset: 52338c94
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52338c94f610611a9e89a6ccbe6f2c6cd768b50a
Stats:     138 lines in 3 files changed: 51 ins; 73 del; 14 mod

8358520: Improve lazy computation in BreakIteratorResourceBundle and related classes

Reviewed-by: naoto, jlu

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

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

From ihse at openjdk.org  Mon Jun  9 13:33:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:33:39 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8 [v2]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <zxrLICCCcLyUhUi55p4ZTPn1ioJOVims3WQ6cImbTzA=.3ebe3fc0-c8c7-4156-b563-e14f04bac137@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

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

 - Merge branch 'master' into utf8-sequences-in-src
 - 8356978: Convert unicode sequences in Java source code to UTF-8

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

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

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

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8 [v3]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Reverting fixes in java.xml and jdk.jdi

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25229/files
  - new: https://git.openjdk.org/jdk/pull/25229/files/37bf474c..5a5d7b7b

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

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

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

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
 <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>
Message-ID: <MlaNiiD6KyfBbrM7Rfs6jeWHg9ZGE-MKa4i2p2Ya4sU=.63399b3c-2270-4916-8055-47e0dac8a29c@github.com>

On Tue, 27 May 2025 16:31:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> @justin-curtis-lu Are these files handled by the translation team?
>
> @magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change.

I have now reverted the changes in java.xml and jdk.jdi. I still think these changes should be made, but it should apparently go through the translation team. @justin-curtis-lu Can you help me file a bug report so this gets done? I'm not sure how to do that. Basically, they will need to revert 5a5d7b7b13158c3b35ed9c433e6fdc34aa20b73d.

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2955820392

From ihse at openjdk.org  Mon Jun  9 13:41:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 13:41:10 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>
Message-ID: <Cpl6dRjtnj-m3gtvHqeiIIVcCdpGWvNoqOUJtoVm7eM=.4a0bfc91-6c1a-4bd0-b8f5-bb89e2a7d732@github.com>

On Tue, 27 May 2025 17:01:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Those TimeZoneNames* resource bundles are in fact leftovers from COMPAT locale provider removal. I am going to remove those files later so you can exclude them.

@naotoj You okay with this?

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2955822435

From aivanov at openjdk.org  Mon Jun  9 14:25:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jun 2025 14:25:55 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8 [v3]
In-Reply-To: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
Message-ID: <cClJUYWcy9oZ_a3qLky54b_n8y4KXr1z9435NpmUoEg=.d03699aa-68c9-49e5-841c-729e8dc4a533@github.com>

On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting fixes in java.xml and jdk.jdi

src/demo/share/jfc/Stylepad/HelloWorld.java line 196:

> 194:             + "???????"
> 195:             + "??? ???"
> 196:             + "?!")

Maybe we can merge the string now:
Suggestion:

            new Run("none", "?????? ?????????? ????!") // Greek

At least two words seem to be split between the wrapped lines.

src/demo/share/jfc/Stylepad/HelloWorld.java line 203:

> 201:         new Paragraph("title", new Run[] {
> 202:             new Run("none", "???? ????"
> 203:             + "????")

Suggestion:

            new Run("none", "???? ????????")

src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja.java line 90:

> 88:             { "japanese.FirstYear",
> 89:                 new String[] {  // first year name
> 90:                     "?",   // "Gan"-nen

Suggestion:

                    "?",       // "Gan"-nen

Preserve comment alignment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135817539
PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135819248
PR Review Comment: https://git.openjdk.org/jdk/pull/25229#discussion_r2135821435

From ihse at openjdk.org  Mon Jun  9 15:52:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 15:52:24 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8 [v4]
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:

 - Fix comment indentation
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Concatenate string literals
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
 - Concatenate string literals
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25229/files
  - new: https://git.openjdk.org/jdk/pull/25229/files/5a5d7b7b..a9f7acc6

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

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

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

From ihse at openjdk.org  Mon Jun  9 15:52:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 15:52:24 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8 [v3]
In-Reply-To: <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <Zdq3BujNi2Cl5avP8MFyhJkTZl5bXJ--K_Du7lw-AUM=.914662bc-d218-4d48-8a05-63efc91e90d6@github.com>
Message-ID: <800l9jY8WcERDH6cBd9Jiw-TXxDWjjsn2kJhxK32HYA=.9eae1609-b9f8-4485-af6c-1808a5735cd0@github.com>

On Mon, 9 Jun 2025 13:41:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting fixes in java.xml and jdk.jdi

Thanks @aivanov-jdk!

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2956185963

From naoto at openjdk.org  Mon Jun  9 16:09:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 16:09:53 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8 [v4]
In-Reply-To: <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <3yL38BGxpG7641rwLTFNIBmL4PbnxVM4-0cdTondkx0=.f9e7da4e-f155-4ff1-ad9b-750311409de7@github.com>
Message-ID: <f86k18YSqMNnLFfAES-56FVmEwDL3qBo2JfZnATOR88=.631be620-509d-459a-8d85-f18e0e8e6af5@github.com>

On Mon, 9 Jun 2025 15:52:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix comment indentation
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Concatenate string literals
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>  - Concatenate string literals
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2910543905

From duke at openjdk.org  Mon Jun  9 17:16:01 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 17:16:01 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with DecimalFormat
 can be improved
Message-ID: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>

This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`

As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.

Testing:
- GHA
- Local run of tier 2 and jtreg:jdk/java/text
- New benchmark: DecimalFormatParseBench

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

Commit messages:
 - Merge branch 'openjdk:master' into digitlist-getdouble-get-long
 - simplify getBigDecimal
 - simplify comparison
 - update comment
 - copyright dates
 - improve getDouble, getLong

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

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

From duke at openjdk.org  Mon Jun  9 17:16:02 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 17:16:02 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <-e5rXCnNcp7f2EdOodLJlsFcytVjKA7Qrwt3HkzGtYU=.c78eb6e8-3f44-4668-bc3a-5c3393a5fe18@github.com>

On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham <duke at openjdk.org> wrote:

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Rough performance results on AArch64 M4:



Original
Benchmark                                   Mode  Cnt      Score     Error   Units
-DecimalFormatParseBench.testParseDoubles  thrpt   15  15200.984 ? 409.547  ops/ms
-DecimalFormatParseBench.testParseLongs    thrpt   15  25777.899 ? 559.096  ops/ms

This PR
Benchmark                                   Mode  Cnt      Score     Error   Units
+DecimalFormatParseBench.testParseDoubles  thrpt   15  28041.325 ? 472.657  ops/ms
+DecimalFormatParseBench.testParseLongs    thrpt   15  34181.146 ? 655.719  ops/ms

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

PR Comment: https://git.openjdk.org/jdk/pull/25644#issuecomment-2940975486

From liach at openjdk.org  Mon Jun  9 17:16:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Jun 2025 17:16:03 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>

On Wed, 4 Jun 2025 18:18:39 GMT, Johannes Graham <duke at openjdk.org> wrote:

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

src/java.base/share/classes/java/text/DigitList.java line 192:

> 190:         long v = Long.parseUnsignedLong(new String(digits, 0, count));
> 191:         if (v < 0) {
> 192:             if (Long.compareUnsigned(v, Long.MIN_VALUE) == 0) {

Unsigned == should be equivalent to signed ==, so `v == Long.MIN_VALUE` should be sufficient.

src/java.base/share/classes/java/text/DigitList.java line 198:

> 196:         }
> 197:         long pow10 = Math.powExact(10L, Math.max(0, decimalAt - count));
> 198:         return Math.multiplyExact(v, pow10);

These two methods throw ArithmeticException. This needs to be rethrown as NumberFormatException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2127580172
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2127581325

From duke at openjdk.org  Mon Jun  9 17:16:03 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 17:16:03 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved
In-Reply-To: <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
Message-ID: <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>

On Wed, 4 Jun 2025 23:15:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> src/java.base/share/classes/java/text/DigitList.java line 198:
> 
>> 196:         }
>> 197:         long pow10 = Math.powExact(10L, Math.max(0, decimalAt - count));
>> 198:         return Math.multiplyExact(v, pow10);
> 
> These two methods throw ArithmeticException. This needs to be rethrown as NumberFormatException.

This one is a little odd. The parse methods that call `getLong` are not supposed to throw `NumberFormatException` either. So wherever `getLong` is called, it must be preceded by a check to `fitsIntoLong`, which should avoid any exceptions here. That said, rethrowing as NFE would avoid new surprises. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2127637333

From liach at openjdk.org  Mon Jun  9 17:16:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Jun 2025 17:16:04 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved
In-Reply-To: <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
Message-ID: <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>

On Wed, 4 Jun 2025 23:59:38 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DigitList.java line 198:
>> 
>>> 196:         }
>>> 197:         long pow10 = Math.powExact(10L, Math.max(0, decimalAt - count));
>>> 198:         return Math.multiplyExact(v, pow10);
>> 
>> These two methods throw ArithmeticException. This needs to be rethrown as NumberFormatException.
>
> This one is a little odd. The parse methods that call `getLong` are not supposed to throw `NumberFormatException` either. So wherever `getLong` is called, it must be preceded by a check to `fitsIntoLong`, which should avoid any exceptions here. That said, rethrowing as NFE would avoid new surprises. What do you think?

I will leave this question to I18N reviewers, who are ultimately in charge of DigitList.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2127673711

From ihse at openjdk.org  Mon Jun  9 18:01:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Jun 2025 18:01:56 GMT
Subject: <i18n dev> Integrated: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <IBsqcOHT6G9vQO7_iXKeYsFa4SuRwl-93HvWt9xyFZA=.6550ebd6-354f-42ae-9733-ece720f75da2@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

This pull request has now been integrated.

Changeset: 156187ac
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/156187accc1c3e2a897ced011727a5c8d8e1b0cf
Stats:     17 lines in 3 files changed: 0 ins; 4 del; 13 mod

8356978: Convert unicode sequences in Java source code to UTF-8

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: naoto, prr, joehw

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

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

From prr at openjdk.org  Mon Jun  9 18:15:07 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Jun 2025 18:15:07 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet API
Message-ID: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>

This is the implementation of JEP 504 - Remove the Applet API.
API changes are
- Remove the entire java.applet package
- Remove the javax/swing/JApplet class
- Remove applet related APIs in java.beans
- Update javadoc referring to applets, including one gif image - now changed to an svg image
- 
Other changes are
- Remove references to the removed classes
- Remove obsolete tests
- Update obsolete code comments

sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
release as this JEP is integrated.

I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

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

Commit messages:
 - 8359053

Changes: https://git.openjdk.org/jdk/pull/25698/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359053
  Stats: 3120 lines in 74 files changed: 114 ins; 2867 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/25698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698

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

From prr at openjdk.org  Mon Jun  9 18:19:54 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Jun 2025 18:19:54 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <WFu6qdUdQg3FqOCCHdZ-tVmWlXjcD9tTCyBseRHLx1k=.552c4bf7-b203-4e70-b9e8-ca8bfc0c73aa@github.com>

On Mon, 9 Jun 2025 18:11:13 GMT, Phil Race <prr at openjdk.org> wrote:

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

test/jdk/ProblemList.txt line 782:

> 780: 
> 781: jdk/internal/loader/URLClassPath/ClassnameCharTest.java         8358729 generic-all
> 782: 

A fix for this test is being worked on - so this problem list addition may be withdrawn later if it is fixed before this PR is integrated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136231123

From naoto at openjdk.org  Mon Jun  9 18:56:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 18:56:45 GMT
Subject: <i18n dev> RFR: 8358626: Emit UTF-8 CLDR resources [v2]
In-Reply-To: <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
 <P7k7-80mHzOV334m1nbODa3b7hIAKEPd1ftRJNytXFQ=.b6f36e21-6ee4-44ac-95ad-2e5275d610dc@github.com>
Message-ID: <UbopHsJ78HDKh5nvcOwaY0B__wb6YIqGe7G1TSzhiLQ=.730a13c6-b24b-4065-86b3-f7efb38f7b6a@github.com>

On Thu, 5 Jun 2025 18:30:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   java.base/Gensrc.gmk comment

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25648#issuecomment-2956654203

From naoto at openjdk.org  Mon Jun  9 19:07:36 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 19:07:36 GMT
Subject: <i18n dev> Integrated: 8358626: Emit UTF-8 CLDR resources
In-Reply-To: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
References: <cKptjhvqzZgJVxatAYzq2bCO9OHPo2SUKsnH74YzMjU=.7f5f688e-a0d4-427c-b29c-85d50b50ca48@github.com>
Message-ID: <JfiJmieYzP39BNGLkb5tepWJBZGGDajE-fB1aNWqPfQ=.8b6c6243-b960-4c48-b65b-da1e2979564a@github.com>

On Wed, 4 Jun 2025 21:54:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Changes to generate CLDR resource bundles in UTF-8 encoding. The resource files in `java.base` are supposed to be US English only, but they also need to use UTF-8 as some of the names are non-ASCII (e.g., T?rkiye)

This pull request has now been integrated.

Changeset: fcb68ea2
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcb68ea22d020d567c560c7bd5976d3c070d9806
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8358626: Emit UTF-8 CLDR resources

Reviewed-by: erikj, vyazici

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

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

From naoto at openjdk.org  Mon Jun  9 19:18:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 19:18:51 GMT
Subject: <i18n dev> RFR: 8358734: Remove JavaTimeSupplementary resource
 bundles
Message-ID: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>

The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation

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

Commit messages:
 - Merge branch 'master' into JDK-8358734-removing-JavaTime-supplemental
 - init

Changes: https://git.openjdk.org/jdk/pull/25699/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358734
  Stats: 740 lines in 10 files changed: 263 ins; 439 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/25699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25699/head:pull/25699

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

From naoto at openjdk.org  Mon Jun  9 20:07:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 20:07:53 GMT
Subject: <i18n dev> RFR: 8358734: Remove JavaTimeSupplementary resource
 bundles [v2]
In-Reply-To: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
Message-ID: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>

> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed the bundle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25699/files
  - new: https://git.openjdk.org/jdk/pull/25699/files/ad5df6ca..020535c3

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

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

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

From aivanov at openjdk.org  Mon Jun  9 20:29:36 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 9 Jun 2025 20:29:36 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>

On Mon, 9 Jun 2025 18:11:13 GMT, Phil Race <prr at openjdk.org> wrote:

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Changes requested by aivanov (Reviewer).

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 437:

> 435:             styleBits = SET(styleBits, TEXTURED, false);
> 436:             styleBits = SET(styleBits, NONACTIVATING, true);
> 437:             styleBits = SET(styleBits, IS_POPUP, true);

Is the code below the comment still required? It looks it was relevant to applets only.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 716:

> 714:                 execute(ptr -> {
> 715:                     if (isPopup) {
> 716:                         CWrapper.NSWindow.orderFrontRegardless(ptr);

Is this still relevant without applets?

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 108:

> 106:      * Checks if vsync painting is requested for {@code rootContainer}
> 107:      *
> 108:      * @param rootContainer topmost container. Should be Window

Suggestion:

     * @param rootContainer topmost container. Should be {@code Window}

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 116:

> 114:     }
> 115: 
> 116:     public static JavaSoundAudioClip create(final URL url) {

Does this method need to be removed?

src/java.desktop/share/classes/java/awt/Component.java line 3938:

> 3936:     /**
> 3937:      * Inner class for flipping buffers on a component.  That component must
> 3938:      * be a {@code Canvas} or {@code Window}

Suggestion:

     * be a {@code Canvas} or {@code Window}.

It ended with a full stop, and the full stop should be preserved.

src/java.desktop/share/classes/java/awt/Component.java line 3988:

> 3986:         /**
> 3987:          * Creates a new flipping buffer strategy for this component.
> 3988:          * The component must be a {@code Canvas} or {@code Window}

Suggestion:

         * The component must be a {@code Canvas} or {@code Window}.

src/java.desktop/share/classes/java/awt/Container.java line 1561:

> 1559:      * <p>
> 1560:      * The {@code Window} class is the validate root in AWT.
> 1561:      *  Swing introduces more validate roots.

Suggestion:

     * Swing introduces more validate roots.

src/java.desktop/share/classes/java/awt/Dialog.java line 174:

> 172:          * from the same toolkit except those from its own child hierarchy.
> 173:          */
> 174:         TOOLKIT_MODAL

Should we add a note that `APPLICATION_MODAL` and `TOOLKIT_MODAL` mean the same thing in the absence of applets or even remove one of them?

src/java.desktop/share/classes/java/awt/Toolkit.java line 1353:

> 1351: 
> 1352:     /**
> 1353:      * {@return the EventQueue for this application}

Suggestion:

     * {@return the {@code EventQueue} for this application}

src/java.desktop/share/classes/java/awt/Toolkit.java line 1360:

> 1358: 
> 1359:     /**
> 1360:      * A method used by toolkit subclasses to get the EventQueue.

Suggestion:

     * A method used by toolkit subclasses to get the {@code EventQueue}.

src/java.desktop/share/classes/java/awt/Toolkit.java line 1362:

> 1360:      * A method used by toolkit subclasses to get the EventQueue.
> 1361:      * This may be more direct or more efficient than calling
> 1362:      * {@code getSystemEventQueue()}

Suggestion:

     * {@code getSystemEventQueue()}.

src/java.desktop/share/classes/javax/swing/JComponent.java line 4684:

> 4682: 
> 4683:     /**
> 4684:      * Returns the top-level ancestor of this component (either the

Suggestion:

     * Returns the top-level ancestor of this component (the

There's only one option left in the parentheses.

src/java.desktop/share/classes/javax/swing/JRootPane.java line 51:

> 49:  * component on the host system) are shown with a heavier box. AWT components in red,
> 50:  * Swing heavyweights in blue.
> 51:  * The three heavyweight JFC/Swing containers ({@code JFrame}, {@code JDialog}, and

Shall we drop _?JFC?_?

src/java.desktop/share/classes/javax/swing/KeyboardManager.java line 135:

> 133: 
> 134:      /**
> 135:        * Find the top focusable Window, or InternalFrame

Suggestion:

       * Find the top focusable Window, or JInternalFrame

Update to the real type used in the condition?

src/java.desktop/share/classes/javax/swing/RepaintManager.java line 55:

> 53:  * As of 1.6 <code>RepaintManager</code> handles repaint requests
> 54:  * for Swing's top level components (
> 55:  * <code>JWindow</code>, <code>JFrame</code> and <code>JDialog</code>).

Suggestion:

 * for Swing's top level components
 * (<code>JWindow</code>, <code>JFrame</code> and <code>JDialog</code>).

Avoid a space after the opening parenthesis.

src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 2196:

> 2194:      * <p>
> 2195:      * The component hierarchy must be displayable up to the toplevel component
> 2196:      * (a {@code Frame}) Otherwise this method returns {@code null}.

Suggestion:

     * (a {@code Frame}). Otherwise this method returns {@code null}.

src/java.desktop/share/classes/javax/swing/UIManager.java line 1457:

> 1455:      * This method is called before any code that depends on the
> 1456:      * <code>AppContext</code> specific LAFState object runs.
> 1457:       In some AppContext cases it's possible for this method

Suggestion:

     * <code>AppContext</code> specific LAFState object runs.
     * In some AppContext cases, it's possible for this method

src/java.desktop/share/classes/sun/awt/AppContext.java line 110:

> 108:  * wants to peek all of the key events on the EventQueue to listen for
> 109:  * passwords; if separate EventQueues are used for each ThreadGroup
> 110:  * using AppContexts, the only key events that code will be able to

Suggestion:

 * using AppContexts, the only key events that the code will be able to

Definite article?

src/java.desktop/share/classes/sun/awt/AppContext.java line 114:

> 112:  * change the Swing default look-and-feel; with that default stored in
> 113:  * an AppContext, the look-and-feel will change without
> 114:  * disrupting other contexts.<p>

Suggestion:

 * disrupting other contexts.

The empty paragraph can be dropped.

src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java line 51:

> 49: 
> 50: /**
> 51:  * A generic container used for embedding Java components,

Suggestion:

 * A generic container used for embedding Java components.

src/java.desktop/share/classes/sun/font/SunFontManager.java line 2484:

> 2482:      * that code is already written to be able to perform properly if called
> 2483:      * to duplicate work. The main difference is that if we detect we are
> 2484:      * An AppContext environment these new fonts

Suggestion:

     * in an AppContext environment these new fonts

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2910990216
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136277388
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136278266
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136281766
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136284478
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136289738
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136290785
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136295472
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136313003
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136343274
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136344490
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136346033
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136365994
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136376363
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136380810
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136390053
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136399517
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136406164
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136419051
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136421035
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136425427
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136436524

From jlu at openjdk.org  Mon Jun  9 20:45:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 20:45:30 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API
In-Reply-To: <WFu6qdUdQg3FqOCCHdZ-tVmWlXjcD9tTCyBseRHLx1k=.552c4bf7-b203-4e70-b9e8-ca8bfc0c73aa@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <WFu6qdUdQg3FqOCCHdZ-tVmWlXjcD9tTCyBseRHLx1k=.552c4bf7-b203-4e70-b9e8-ca8bfc0c73aa@github.com>
Message-ID: <EuuaFGly5DQOH5YzdrDkO2akvU36upPDQYYfy_S632w=.60fadcc5-74d4-41a9-add6-b5220c94d619@github.com>

On Mon, 9 Jun 2025 18:17:45 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> test/jdk/ProblemList.txt line 782:
> 
>> 780: 
>> 781: jdk/internal/loader/URLClassPath/ClassnameCharTest.java         8358729 generic-all
>> 782: 
> 
> A fix for this test is being worked on - so this problem list addition may be withdrawn later if it is fixed before this PR is integrated.

PR for this issue has been created here: https://github.com/openjdk/jdk/pull/25703.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136480341

From jlu at openjdk.org  Mon Jun  9 20:52:39 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 20:52:39 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
Message-ID: <FK3TVafBhdADbrTLUmZzOsY_VZpwdqHs_3jKRufINlo=.ae274122-2d0c-41d2-8d66-32cb63330c8b@github.com>

On Thu, 5 Jun 2025 20:29:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
>> 
>> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
>> 
>> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
>> 
>> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25646#issuecomment-2956999624

From jlu at openjdk.org  Mon Jun  9 20:52:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 20:52:40 GMT
Subject: <i18n dev> RFR: 8358426: Improve lazy computation in Locale [v2]
In-Reply-To: <nXLruLQd1Zzx4tlLaTbi6VhM9epxWMyRzGo0dTv17Rc=.d239e5e9-80db-4d3a-9cb4-0adbceb97a58@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
 <rTqhiIsNXTejPYZE2wRgQdryau_JUVOcXbkcRipfwh8=.f5f6f1a5-e528-4d27-bc3e-4cf0afc4619c@github.com>
 <nXLruLQd1Zzx4tlLaTbi6VhM9epxWMyRzGo0dTv17Rc=.d239e5e9-80db-4d3a-9cb4-0adbceb97a58@github.com>
Message-ID: <J5-Bj0yCXfogXFNooEGU7JbXbFkK0pXXLeWgWJ9HH5w=.6cb25f91-b7bc-4fdc-9663-f079adac6a54@github.com>

On Sat, 7 Jun 2025 17:36:40 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review - Moving all ISO resources to LocaleISOData & blessed modifier order for languageTag
>
> src/java.base/share/classes/java/util/Locale.java line 1282:
> 
>> 1280:     public static Set<String> getISOCountries(IsoCountryCode type) {
>> 1281:         Objects.requireNonNull(type);
>> 1282:         return switch (type) {
> 
> The body of this method could also be moved to a method in `LocaleISOData`

I think it's OK as is, don't want to force re-approvals. Currently it is consistent with the other ISO related methods in `Locale`, which grab the ISO resources from `LocaleISOData` but handle some logic on their own as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25646#discussion_r2136488492

From jlu at openjdk.org  Mon Jun  9 20:52:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 20:52:41 GMT
Subject: <i18n dev> Integrated: 8358426: Improve lazy computation in Locale
In-Reply-To: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
References: <nRky6gCmVdQWUTvFydVhGm9g593GKq5oPYW6bNvdjhc=.89c8cfe8-30a1-4356-a928-31fa1640440a@github.com>
Message-ID: <SSKmh5EWAzYwNCj7pA_1TSf68hubP-F-xekVXq8k3WM=.a7bde6ed-7c1e-47d1-b9d0-7f65dd99c8b8@github.com>

On Wed, 4 Jun 2025 21:20:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which improves occurrences of lazy computation in `Locale` and `BaseLocale`.
> 
> Existing lazy initialization strategies such as CHM, static nested class, and local inner class are replaced with Stable Values.
> 
> Lambda usage is intentionally avoided in this change during `Locale` creation and in static fields due to potential startup performance degradation as noted by [JDK-8331932](https://bugs.openjdk.org/browse/JDK-8331932).
> 
> Rather than convert `iso3166CodesMap` to a Stable Map, each ISO 3166 resource is represented as a SV. Also, I did not think it was necessary to maintain a SV for _both_ the array and set of ISO3166-1 alpha-2 codes.

This pull request has now been integrated.

Changeset: cd9b1bc8
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd9b1bc820540184c79dd1957edc7ad4e8e469dc
Stats:     242 lines in 3 files changed: 101 ins; 94 del; 47 mod

8358426: Improve lazy computation in Locale

Reviewed-by: naoto, liach

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

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

From naoto at openjdk.org  Mon Jun  9 21:47:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 21:47:37 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved
In-Reply-To: <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
Message-ID: <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>

On Thu, 5 Jun 2025 00:10:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This one is a little odd. The parse methods that call `getLong` are not supposed to throw `NumberFormatException` either. So wherever `getLong` is called, it must be preceded by a check to `fitsIntoLong`, which should avoid any exceptions here. That said, rethrowing as NFE would avoid new surprises. What do you think?
>
> I will leave this question to I18N reviewers, who are ultimately in charge of DigitList.

The existing implementation does not throw `NumberFormatException`/`ArithmeticException`, but `ParseException` if parsing is failing. I would expect the same here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136557633

From prr at openjdk.org  Mon Jun  9 21:48:59 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Jun 2025 21:48:59 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/604d78c9..82f0ee55

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

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

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

From prr at openjdk.org  Mon Jun  9 21:49:01 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Jun 2025 21:49:01 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
Message-ID: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>

On Mon, 9 Jun 2025 18:51:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 437:
> 
>> 435:             styleBits = SET(styleBits, TEXTURED, false);
>> 436:             styleBits = SET(styleBits, NONACTIVATING, true);
>> 437:             styleBits = SET(styleBits, IS_POPUP, true);
> 
> Is the code below the comment still required? It looks it was relevant to applets only.

Since the code isn't conditionalised on applets, I don't think it should be changed as part of this PR

> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 716:
> 
>> 714:                 execute(ptr -> {
>> 715:                     if (isPopup) {
>> 716:                         CWrapper.NSWindow.orderFrontRegardless(ptr);
> 
> Is this still relevant without applets?

Since the code isn't conditionalised on applets, I don't think it should be changed as part of this PR

> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 108:
> 
>> 106:      * Checks if vsync painting is requested for {@code rootContainer}
>> 107:      *
>> 108:      * @param rootContainer topmost container. Should be Window
> 
> Suggestion:
> 
>      * @param rootContainer topmost container. Should be {@code Window}

This isn't public API doc, so I'm not inclined to go updating it any more than I have to.

> src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 116:
> 
>> 114:     }
>> 115: 
>> 116:     public static JavaSoundAudioClip create(final URL url) {
> 
> Does this method need to be removed?

It was used by AudioClip. I removed it, nothing broke, so it must now be un-used. So why not remove it ?

> src/java.desktop/share/classes/java/awt/Component.java line 3938:
> 
>> 3936:     /**
>> 3937:      * Inner class for flipping buffers on a component.  That component must
>> 3938:      * be a {@code Canvas} or {@code Window}
> 
> Suggestion:
> 
>      * be a {@code Canvas} or {@code Window}.
> 
> It ended with a full stop, and the full stop should be preserved.

added back

> src/java.desktop/share/classes/java/awt/Component.java line 3988:
> 
>> 3986:         /**
>> 3987:          * Creates a new flipping buffer strategy for this component.
>> 3988:          * The component must be a {@code Canvas} or {@code Window}
> 
> Suggestion:
> 
>          * The component must be a {@code Canvas} or {@code Window}.

full stop added.

> src/java.desktop/share/classes/java/awt/Container.java line 1561:
> 
>> 1559:      * <p>
>> 1560:      * The {@code Window} class is the validate root in AWT.
>> 1561:      *  Swing introduces more validate roots.
> 
> Suggestion:
> 
>      * Swing introduces more validate roots.

space removed

> src/java.desktop/share/classes/java/awt/Dialog.java line 174:
> 
>> 172:          * from the same toolkit except those from its own child hierarchy.
>> 173:          */
>> 174:         TOOLKIT_MODAL
> 
> Should we add a note that `APPLICATION_MODAL` and `TOOLKIT_MODAL` mean the same thing in the absence of applets or even remove one of them?

Yes, It didn't escape me that they mean essentially the same thing, even more so than they did before
Theoretically there can be more than one toolkit, although it is not really possible.

Addressing the nuances of that is outside the scope of this change, so I made the minimum doc change and removing applet isn't the right time to add advice about which to use. So future work there.
And very unlikely to remove either of them as I suspect the similarities mean that developers probably are 50:50 in which they used, so we'd just break (more) apps if we did.

> src/java.desktop/share/classes/java/awt/Toolkit.java line 1353:
> 
>> 1351: 
>> 1352:     /**
>> 1353:      * {@return the EventQueue for this application}
> 
> Suggestion:
> 
>      * {@return the {@code EventQueue} for this application}

ok

> src/java.desktop/share/classes/java/awt/Toolkit.java line 1360:
> 
>> 1358: 
>> 1359:     /**
>> 1360:      * A method used by toolkit subclasses to get the EventQueue.
> 
> Suggestion:
> 
>      * A method used by toolkit subclasses to get the {@code EventQueue}.

ok

> src/java.desktop/share/classes/java/awt/Toolkit.java line 1362:
> 
>> 1360:      * A method used by toolkit subclasses to get the EventQueue.
>> 1361:      * This may be more direct or more efficient than calling
>> 1362:      * {@code getSystemEventQueue()}
> 
> Suggestion:
> 
>      * {@code getSystemEventQueue()}.

full stop added

> src/java.desktop/share/classes/javax/swing/KeyboardManager.java line 135:
> 
>> 133: 
>> 134:      /**
>> 135:        * Find the top focusable Window, or InternalFrame
> 
> Suggestion:
> 
>        * Find the top focusable Window, or JInternalFrame
> 
> Update to the real type used in the condition?

a private method in an internal class and the same the same is elsewhere in this file. Not worth changing.

> src/java.desktop/share/classes/javax/swing/RepaintManager.java line 55:
> 
>> 53:  * As of 1.6 <code>RepaintManager</code> handles repaint requests
>> 54:  * for Swing's top level components (
>> 55:  * <code>JWindow</code>, <code>JFrame</code> and <code>JDialog</code>).
> 
> Suggestion:
> 
>  * for Swing's top level components
>  * (<code>JWindow</code>, <code>JFrame</code> and <code>JDialog</code>).
> 
> Avoid a space after the opening parenthesis.

ok

> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 2196:
> 
>> 2194:      * <p>
>> 2195:      * The component hierarchy must be displayable up to the toplevel component
>> 2196:      * (a {@code Frame}) Otherwise this method returns {@code null}.
> 
> Suggestion:
> 
>      * (a {@code Frame}). Otherwise this method returns {@code null}.

full stop added.

> src/java.desktop/share/classes/javax/swing/UIManager.java line 1457:
> 
>> 1455:      * This method is called before any code that depends on the
>> 1456:      * <code>AppContext</code> specific LAFState object runs.
>> 1457:       In some AppContext cases it's possible for this method
> 
> Suggestion:
> 
>      * <code>AppContext</code> specific LAFState object runs.
>      * In some AppContext cases, it's possible for this method

fixed

> src/java.desktop/share/classes/sun/awt/AppContext.java line 110:
> 
>> 108:  * wants to peek all of the key events on the EventQueue to listen for
>> 109:  * passwords; if separate EventQueues are used for each ThreadGroup
>> 110:  * using AppContexts, the only key events that code will be able to
> 
> Suggestion:
> 
>  * using AppContexts, the only key events that the code will be able to
> 
> Definite article?

not here.

> src/java.desktop/share/classes/sun/awt/AppContext.java line 114:
> 
>> 112:  * change the Swing default look-and-feel; with that default stored in
>> 113:  * an AppContext, the look-and-feel will change without
>> 114:  * disrupting other contexts.<p>
> 
> Suggestion:
> 
>  * disrupting other contexts.
> 
> The empty paragraph can be dropped.

ok

> src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java line 51:
> 
>> 49: 
>> 50: /**
>> 51:  * A generic container used for embedding Java components,
> 
> Suggestion:
> 
>  * A generic container used for embedding Java components.

ok

> src/java.desktop/share/classes/sun/font/SunFontManager.java line 2484:
> 
>> 2482:      * that code is already written to be able to perform properly if called
>> 2483:      * to duplicate work. The main difference is that if we detect we are
>> 2484:      * An AppContext environment these new fonts
> 
> Suggestion:
> 
>      * in an AppContext environment these new fonts

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136487935
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136488391
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136490304
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136492907
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136494512
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136495544
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136496455
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136509376
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136544801
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136545330
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136546411
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136515250
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136548505
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136517418
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136526160
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136526991
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136549954
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136550460
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136551402

From prr at openjdk.org  Mon Jun  9 21:49:01 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 9 Jun 2025 21:49:01 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <EuuaFGly5DQOH5YzdrDkO2akvU36upPDQYYfy_S632w=.60fadcc5-74d4-41a9-add6-b5220c94d619@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <WFu6qdUdQg3FqOCCHdZ-tVmWlXjcD9tTCyBseRHLx1k=.552c4bf7-b203-4e70-b9e8-ca8bfc0c73aa@github.com>
 <EuuaFGly5DQOH5YzdrDkO2akvU36upPDQYYfy_S632w=.60fadcc5-74d4-41a9-add6-b5220c94d619@github.com>
Message-ID: <NRMHh_Rj41X5PjfTPzIXl-7IqiwaOx9klvXQUxR_9Ss=.577f1f92-a8e3-4654-aba6-775b6770c235@github.com>

On Mon, 9 Jun 2025 20:43:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 782:
>> 
>>> 780: 
>>> 781: jdk/internal/loader/URLClassPath/ClassnameCharTest.java         8358729 generic-all
>>> 782: 
>> 
>> A fix for this test is being worked on - so this problem list addition may be withdrawn later if it is fixed before this PR is integrated.
>
> PR for this issue has been created here: https://github.com/openjdk/jdk/pull/25703.

noted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2136551774

From duke at openjdk.org  Mon Jun  9 22:07:27 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 22:07:27 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved
In-Reply-To: <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
 <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
Message-ID: <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>

On Mon, 9 Jun 2025 21:45:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I will leave this question to I18N reviewers, who are ultimately in charge of DigitList.
>
> The existing implementation does not throw `NumberFormatException`/`ArithmeticException`, but `ParseException` if parsing is failing. I would expect the same here.

Sorry, I'm not seeing where the original could throw ParseException.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136574842

From naoto at openjdk.org  Mon Jun  9 22:11:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 22:11:26 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved
In-Reply-To: <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
 <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
 <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>
Message-ID: <TcP37iElvBcnrVAw_9Rz9EpbWSn3MeXBWiU7aqp2Q8U=.3783fc7e-542c-4477-9aba-0af091044912@github.com>

On Mon, 9 Jun 2025 22:03:37 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> The existing implementation does not throw `NumberFormatException`/`ArithmeticException`, but `ParseException` if parsing is failing. I would expect the same here.
>
> Sorry, I'm not seeing where the original could throw ParseException.

Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw NumberFormatException/ArithmeticException, but ParseException, so if this piece of code need to throw something, it should be `ParseException`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136578931

From duke at openjdk.org  Mon Jun  9 22:46:50 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 22:46:50 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v2]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <jNo1y3QVwzaJ-e2yXXZH-hFmbtRerqT4vSytEHBN2x0=.9725dfee-cd87-4739-b313-c23af309d4ea@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  catch ArithmeticException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/a85ddd82..da9e4aea

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

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

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

From duke at openjdk.org  Mon Jun  9 22:46:50 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 9 Jun 2025 22:46:50 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v2]
In-Reply-To: <TcP37iElvBcnrVAw_9Rz9EpbWSn3MeXBWiU7aqp2Q8U=.3783fc7e-542c-4477-9aba-0af091044912@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
 <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
 <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>
 <TcP37iElvBcnrVAw_9Rz9EpbWSn3MeXBWiU7aqp2Q8U=.3783fc7e-542c-4477-9aba-0af091044912@github.com>
Message-ID: <MgGR7p_lhYuMEEq4zFp_zGYx8t6yj74D-8QGbJT4Q-g=.e66bac23-0454-4a9c-9b10-b1954b8e218b@github.com>

On Mon, 9 Jun 2025 22:08:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Sorry, I'm not seeing where the original could throw ParseException.
>
> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw NumberFormatException/ArithmeticException, but ParseException, so if this piece of code need to throw something, it should be `ParseException`

The `parse()` methods where this code gets used in `DecimalFormat` don't throw `ParseException`. The current calls to `getLong` always are guarded with a call to `fitsIntoLong`, which should avoid any exceptions actually being thrown here. So there is no parse failure as such - instead it tries to parse it as a `double` or a `BigDecimal`. If getLong were to be called without the guard, the exception would have come from `Long.parseLong`, which throws a `NumberFormatException`.

I've added a commit to follow @liach's suggestion to at least rethrow the ArithmeticException so as to not introduce new exceptions into the mix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136611661

From jlu at openjdk.org  Mon Jun  9 23:11:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 23:11:28 GMT
Subject: <i18n dev> RFR: 8358734: Remove JavaTimeSupplementary resource
 bundles [v2]
In-Reply-To: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
Message-ID: <tUxMODtJoAQUMb8LNstGAy_KJafVDPq6lxcj5oE4Btg=.7b999ead-f27a-42a8-bec9-dc906407ce95@github.com>

On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the bundle

Cleanup looks good to me.

src/java.base/share/classes/sun/util/resources/LocaleData.java line 214:

> 212:                 int lastDot = baseName.lastIndexOf('.');
> 213:                 String category = (lastDot >= 0) ? baseName.substring(lastDot + 1) : baseName;
> 214:                 if (adapter instanceof JRELocaleProviderAdapter jlpa) {

For safety, should we have some type of failure if this is not true, similar to the previous `CCE`.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25699#pullrequestreview-2911552652
PR Review Comment: https://git.openjdk.org/jdk/pull/25699#discussion_r2136628185

From naoto at openjdk.org  Mon Jun  9 23:44:35 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Jun 2025 23:44:35 GMT
Subject: <i18n dev> RFR: 8358734: Remove JavaTimeSupplementary resource
 bundles [v2]
In-Reply-To: <tUxMODtJoAQUMb8LNstGAy_KJafVDPq6lxcj5oE4Btg=.7b999ead-f27a-42a8-bec9-dc906407ce95@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
 <tUxMODtJoAQUMb8LNstGAy_KJafVDPq6lxcj5oE4Btg=.7b999ead-f27a-42a8-bec9-dc906407ce95@github.com>
Message-ID: <Vk7hNIfDsLnyIrQ-inuFWIwSUJcJuIPYKAHiPPrv58M=.8ebdad86-29bf-4564-84b6-3054a099d549@github.com>

On Mon, 9 Jun 2025 22:57:24 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed the bundle
>
> src/java.base/share/classes/sun/util/resources/LocaleData.java line 214:
> 
>> 212:                 int lastDot = baseName.lastIndexOf('.');
>> 213:                 String category = (lastDot >= 0) ? baseName.substring(lastDot + 1) : baseName;
>> 214:                 if (adapter instanceof JRELocaleProviderAdapter jlpa) {
> 
> For safety, should we have some type of failure if this is not true, similar to the previous `CCE`.

I think this is acceptable.  If, for some reason, `adapter` is not an instance, it will simply be ignored. That cast was a mere artifact from a time before we had this `instanceof` construct and we knew it wouldn't throw a CCE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25699#discussion_r2136674459

From jlu at openjdk.org  Mon Jun  9 23:48:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Jun 2025 23:48:29 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v2]
In-Reply-To: <jNo1y3QVwzaJ-e2yXXZH-hFmbtRerqT4vSytEHBN2x0=.9725dfee-cd87-4739-b313-c23af309d4ea@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <jNo1y3QVwzaJ-e2yXXZH-hFmbtRerqT4vSytEHBN2x0=.9725dfee-cd87-4739-b313-c23af309d4ea@github.com>
Message-ID: <Du9MYXbdEwDCcfImykmsIkXrXYB59O2VZwd3bH3YbNk=.c77cc3ab-5a5f-457e-9239-a23127587cf4@github.com>

On Mon, 9 Jun 2025 22:46:50 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   catch ArithmeticException

Thanks for the improvements. I think we need to prioritize behavioral compatibility with this change, so we will want to run the JCK tests as well for the extra safety.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 134:

> 132:      * @return The double-precision value of the conversion
> 133:      */
> 134:     public static double parseDoubleDigits(int decExp, char[] digits, int length) throws NumberFormatException {

I don't think this method needs to declare `NFE` in the signature since it is not reading in any strings so it should not throw.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1848:

> 1846:             buf[i] = (byte) digits[i];
> 1847:         }
> 1848:         return new ASCIIToBinaryBuffer(false, decExp, buf, length);

Since `negSign` is always false, adding a _positive_ somewhere to the method name might be helpful/explicit. Although you could argue that the array parameter itself is telling enough, but one could misinterpret the char array as including a sign character.

test/jdk/java/text/Format/DecimalFormat/CloneTest.java line 98:

> 96:                 }
> 97: 
> 98:                 Object tempBuilder = valFromDigitList(original, "tempBuilder");

Since this is required as a direct result of this change, I think that warrants adding the JBS bug ID to the Jtreg header.

test/micro/org/openjdk/bench/java/text/DecimalFormatParseBench.java line 28:

> 26: import java.text.DecimalFormat;
> 27: import java.text.ParseException;
> 28: import java.util.Locale;

Looks unused.

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

PR Review: https://git.openjdk.org/jdk/pull/25644#pullrequestreview-2911579886
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136657118
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136676237
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136643849
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2136644390

From joehw at openjdk.org  Tue Jun 10 01:13:27 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 10 Jun 2025 01:13:27 GMT
Subject: <i18n dev> RFR: 8358734: Remove JavaTimeSupplementary resource
 bundles [v2]
In-Reply-To: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
Message-ID: <qKaksraWAM6-ppA3k3DS4qGMZ4fFxLLB4nWjUJxssws=.a29f1fe1-b447-41da-981f-1296171a250d@github.com>

On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the bundle

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25699#pullrequestreview-2911715083

From swen at openjdk.org  Tue Jun 10 01:20:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 10 Jun 2025 01:20:59 GMT
Subject: <i18n dev> RFR: 8359068: Remove the unused Cstyle code in
 GenerateCharacter
Message-ID: <M_mEhCfRdGbZ5She_lPZaqbGtbm0D-Q8e9PEv-3Mc8s=.282ca66c-1de2-4adc-8dc8-04d5e4041a4a@github.com>

According to the suggestions of @cl4es and @naotoj, Cstyle is no longer used in GenerateCharacter, so remove the Cstyle related code.

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

Commit messages:
 - remove `Csyntax`

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

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

From iris at openjdk.org  Tue Jun 10 01:40:27 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 10 Jun 2025 01:40:27 GMT
Subject: <i18n dev> RFR: 8358734: Remove JavaTimeSupplementary resource
 bundles [v2]
In-Reply-To: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
Message-ID: <1qohGcWf_E6w7vdFzI5wYF_lx9mGr5q9QOffb3l-olI=.517a6473-afb8-427f-b3dd-0065ecc6443d@github.com>

On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the bundle

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25699#pullrequestreview-2911742189

From aivanov at openjdk.org  Tue Jun 10 11:43:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jun 2025 11:43:31 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
 <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>
Message-ID: <x8TJbtS43E5xHiAzQR8M9yaW7V7Y49ChQOtfpmf1ThI=.0435c5c0-48c6-4267-b754-fd0540dcd286@github.com>

On Mon, 9 Jun 2025 20:48:47 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java line 437:
>> 
>>> 435:             styleBits = SET(styleBits, TEXTURED, false);
>>> 436:             styleBits = SET(styleBits, NONACTIVATING, true);
>>> 437:             styleBits = SET(styleBits, IS_POPUP, true);
>> 
>> Is the code below the comment still required? It looks it was relevant to applets only.
>
> Since the code isn't conditionalised on applets, I don't think it should be changed as part of this PR

Shall I submit a bug to consider removing this code?

Without the comment and an issue to track it, no one will ever remember to look into it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2137663905

From aivanov at openjdk.org  Tue Jun 10 11:51:30 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jun 2025 11:51:30 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
 <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>
Message-ID: <0pcnXdSjrCcQNZJtt0UgAY0a2yWItZEq30BcJFdbGF8=.83799898-1d0a-4d24-93fd-cd618b108c5f@github.com>

On Mon, 9 Jun 2025 20:50:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java line 108:
>> 
>>> 106:      * Checks if vsync painting is requested for {@code rootContainer}
>>> 107:      *
>>> 108:      * @param rootContainer topmost container. Should be Window
>> 
>> Suggestion:
>> 
>>      * @param rootContainer topmost container. Should be {@code Window}
>
> This isn't public API doc, so I'm not inclined to go updating it any more than I have to.

You have kept `@code` for [`setVsyncRequested`](https://github.com/openjdk/jdk/pull/25698/files/604d78c9e465abe6853f97b328a0c6f13c276a53#diff-52524c1d4891d53a8f9acc07e5e266ea7a07ee5ac3f84c41c240c26409719453R91); for consistency `isVsyncRequested` should have `{@code Window}` too.

>> src/java.desktop/share/classes/java/awt/Component.java line 3938:
>> 
>>> 3936:     /**
>>> 3937:      * Inner class for flipping buffers on a component.  That component must
>>> 3938:      * be a {@code Canvas} or {@code Window}
>> 
>> Suggestion:
>> 
>>      * be a {@code Canvas} or {@code Window}.
>> 
>> It ended with a full stop, and the full stop should be preserved.
>
> added back

Still missing here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2137673477
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2137677189

From duke at openjdk.org  Tue Jun 10 12:08:41 2025
From: duke at openjdk.org (Abhishek N)
Date: Tue, 10 Jun 2025 12:08:41 GMT
Subject: <i18n dev> Withdrawn: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance()
In-Reply-To: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
Message-ID: <4YE0Py2WUEbdDOUOxLosrGdYiDUUL7Mk40yRv5l04j0=.ba7cfefa-531c-4ea2-b610-dfa0a09dc24a@github.com>

On Tue, 6 May 2025 07:25:36 GMT, Abhishek N <duke at openjdk.org> wrote:

> Create a Test case to have special cases coverage for currency.getInstance().
> 
> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
> 
> test results:
> 
> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
> Directory "JTwork" not found: creating
> Directory "JTreport" not found: creating
> Test results: passed: 1
> Report written to JTreport\html\report.html
> Results written to JTwork

This pull request has been closed without being integrated.

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

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

From aivanov at openjdk.org  Tue Jun 10 12:31:30 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 10 Jun 2025 12:31:30 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
Message-ID: <sI1B26mQD2LMg2TqFq3QM1kkPHqwtukg13J1BvYfeCM=.dab1b26b-04b4-437c-9acc-2265bf0cf9e6@github.com>

On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2913352529

From kizune at openjdk.org  Tue Jun 10 14:51:31 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 10 Jun 2025 14:51:31 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
Message-ID: <L1QFwhtcCcTgQ_9f2yNDKyzVoW1A2Quuyq2ZVw8UB4I=.cb412bc7-63f3-4ac1-b8f2-79246d868c39@github.com>

On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2913923933

From duke at openjdk.org  Tue Jun 10 15:41:47 2025
From: duke at openjdk.org (Johannes Graham)
Date: Tue, 10 Jun 2025 15:41:47 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v3]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/da9e4aea..6953dcfc

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

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

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

From naoto at openjdk.org  Tue Jun 10 15:49:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Jun 2025 15:49:38 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v3]
In-Reply-To: <MgGR7p_lhYuMEEq4zFp_zGYx8t6yj74D-8QGbJT4Q-g=.e66bac23-0454-4a9c-9b10-b1954b8e218b@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <5PIQmkiXUCFHmct7VU4lEkFXWNFerEYdWN40cw7H10k=.97e3ea62-8c91-4711-8864-090330e270ac@github.com>
 <6fAXoHW5qw6s-IzMjisZcYYQ9nxee7mZeVDJl76BW_8=.68ff17f1-01ce-4b50-b257-a6e54db79f14@github.com>
 <brpBKJEdZwELSiDmMHYv8R-grQz-Ospsu6g_bpYFLMk=.ee5f347f-5a85-4363-9614-56d8dbd22c11@github.com>
 <MvD5955Lp-Pe192CGu2AzaQ7V7wD52m2E_JLuMRidjg=.7c54a0c7-fb65-4c89-ac60-d90ff9ca300a@github.com>
 <EJN0jGyONSmv2OqjFQU5hXPq1i3bS-_Vi0FJh7HYEoc=.c9b613a3-8833-4b52-a0d3-c3168cad1701@github.com>
 <TcP37iElvBcnrVAw_9Rz9EpbWSn3MeXBWiU7aqp2Q8U=.3783fc7e-542c-4477-9aba-0af091044912@github.com>
 <MgGR7p_lhYuMEEq4zFp_zGYx8t6yj74D-8QGbJT4Q-g=.e66bac23-0454-4a9c-9b10-b1954b8e218b@github.com>
Message-ID: <50Iv4eohLdoAeHlQ5bwh4CCPKuuLJJu46P_jcE4JJ84=.9271d6a9-a420-4382-b5bc-4e88620e3f00@github.com>

On Mon, 9 Jun 2025 22:41:21 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Sorry if I was unclear. I mean the `parse()` in the NumberFormat do not throw NumberFormatException/ArithmeticException, but ParseException, so if this piece of code need to throw something, it should be `ParseException`
>
> The `parse()` methods where this code gets used in `DecimalFormat` unfortunately don't throw `ParseException`. The current calls to `getLong` always are guarded with a call to `fitsIntoLong`, which should avoid any exceptions actually being thrown here. So there is no parse failure as such - instead it tries to parse it as a `double` or a `BigDecimal`. If getLong were to be called without the guard, the exception would have come from `Long.parseLong`, which throws a `NumberFormatException`.
> 
> I've added a commit to follow @liach's suggestion to at least handle the ArithmeticException so as to not introduce new exceptions into the mix.

OK, sounds reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2138252488

From prr at openjdk.org  Tue Jun 10 18:02:31 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Jun 2025 18:02:31 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <x8TJbtS43E5xHiAzQR8M9yaW7V7Y49ChQOtfpmf1ThI=.0435c5c0-48c6-4267-b754-fd0540dcd286@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
 <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>
 <x8TJbtS43E5xHiAzQR8M9yaW7V7Y49ChQOtfpmf1ThI=.0435c5c0-48c6-4267-b754-fd0540dcd286@github.com>
Message-ID: <K9CWTpAsp0wdAmFog0VthzHwVfbHKqqxn17Yj5tTuOU=.0fd9f3f6-3cff-4a38-8026-3125e44b70db@github.com>

On Tue, 10 Jun 2025 11:41:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Since the code isn't conditionalised on applets, I don't think it should be changed as part of this PR
>
> Shall I submit a bug to consider removing this code?
> 
> Without the comment and an issue to track it, no one will ever remember to look into it.

yes, go ahead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138490633

From naoto at openjdk.org  Tue Jun 10 18:42:43 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 10 Jun 2025 18:42:43 GMT
Subject: <i18n dev> RFR: 8358819: The first year is not displayed correctly
 in Japanese Calendar
Message-ID: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>

This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/25732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358819
  Stats: 197 lines in 3 files changed: 120 ins; 66 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25732/head:pull/25732

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

From achung at openjdk.org  Tue Jun 10 20:59:31 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 10 Jun 2025 20:59:31 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
Message-ID: <We5C6WPgWm6b8mXQM_SQlj9dsjhzdCBD1INVGbLMR9I=.259776f2-c75d-4136-b228-532ab9a84476@github.com>

On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

src/java.desktop/share/classes/java/awt/Polygon.java line 163:

> 161:             throw new NegativeArraySizeException("npoints < 0");
> 162:         }
> 163:         // Fix 6343431: compatibility problems if arrays are not

should this comment just be removed entirely?

src/java.desktop/share/classes/java/awt/Toolkit.java line 1353:

> 1351: 
> 1352:     /**
> 1353:      * {@return the {@code EventQueue} for this application}

why is this specification in brackets?

src/java.desktop/share/classes/javax/swing/JComponent.java line 108:

> 106:  * whose root is a top-level Swing container.
> 107:  * Top-level Swing containers --
> 108:  * such as <code>JFrame</code>, <code>JDialog</code> --

"and" instead of comma maybe?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138745729
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138747196
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138750561

From prr at openjdk.org  Tue Jun 10 21:13:33 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Jun 2025 21:13:33 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
Message-ID: <YMhdhAanE964KTUcgZv4ofIIakijoByyeD_W6S8S5DA=.4bd6659d-1f48-42b3-ac87-09773fe20d17@github.com>

On Mon, 9 Jun 2025 21:48:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

The CSR is now ready for a review : https://bugs.openjdk.org/browse/JDK-8359058

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

PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960591023

From prr at openjdk.org  Tue Jun 10 21:28:56 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Jun 2025 21:28:56 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v3]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <gmTDT8Vbf12_OO7jMgmUTNlK8wEH8Y5np2PhFFoybps=.04b234fc-c160-45f4-ae7b-fa242cd72e72@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/82f0ee55..a5b4ca5e

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

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

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

From prr at openjdk.org  Tue Jun 10 21:28:56 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Jun 2025 21:28:56 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v2]
In-Reply-To: <We5C6WPgWm6b8mXQM_SQlj9dsjhzdCBD1INVGbLMR9I=.259776f2-c75d-4136-b228-532ab9a84476@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Ava9vrv0urodUex7BN7w4l7HijWjAmr2qS6oB4wM2hQ=.73bc31f5-d496-4665-a31c-674c890c759a@github.com>
 <We5C6WPgWm6b8mXQM_SQlj9dsjhzdCBD1INVGbLMR9I=.259776f2-c75d-4136-b228-532ab9a84476@github.com>
Message-ID: <x2-5Ic87V-t5cjv_EDBmkw64xCc82ZeE37AXHLP7jmY=.a35657a5-8e62-4d69-9b23-fa85224c7bc9@github.com>

On Tue, 10 Jun 2025 20:50:07 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> src/java.desktop/share/classes/java/awt/Polygon.java line 163:
> 
>> 161:             throw new NegativeArraySizeException("npoints < 0");
>> 162:         }
>> 163:         // Fix 6343431: compatibility problems if arrays are not
> 
> should this comment just be removed entirely?

The bug wasn't specific to applets.

> src/java.desktop/share/classes/java/awt/Toolkit.java line 1353:
> 
>> 1351: 
>> 1352:     /**
>> 1353:      * {@return the {@code EventQueue} for this application}
> 
> why is this specification in brackets?

It's a nice feature I only learned about recently.
It generates a comment as well as an @return line.

> src/java.desktop/share/classes/javax/swing/JComponent.java line 108:
> 
>> 106:  * whose root is a top-level Swing container.
>> 107:  * Top-level Swing containers --
>> 108:  * such as <code>JFrame</code>, <code>JDialog</code> --
> 
> "and" instead of comma maybe?

oh yes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138781413
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138782561
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2138784961

From kcr at openjdk.org  Tue Jun 10 21:36:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Jun 2025 21:36:30 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v3]
In-Reply-To: <gmTDT8Vbf12_OO7jMgmUTNlK8wEH8Y5np2PhFFoybps=.04b234fc-c160-45f4-ae7b-fa242cd72e72@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <gmTDT8Vbf12_OO7jMgmUTNlK8wEH8Y5np2PhFFoybps=.04b234fc-c160-45f4-ae7b-fa242cd72e72@github.com>
Message-ID: <HTOayx0_fQogqBWm40f0qcXh74rVTPFXwlq7-e7rhRs=.4c3bb37b-65fd-459b-9d70-bfabb67dc39d@github.com>

On Tue, 10 Jun 2025 21:28:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

The following files still reference the now-removed applet classes and will fail to compile. Are they not included in any tier testing?


test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java
test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphPanel.java
test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/layout.java
test/jdk/java/beans/Performance/TestIntrospector.java


The following javadoc tests reference the java.applet package. I don't know whether or not this will cause test failures:


test/langtools/jdk/javadoc/doclet/JavascriptWinTitle/package-list
test/langtools/jdk/javadoc/doclet/testLinkOption/jdk/package-list
test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list


The following refer to applets in API documentation, so you might consider updating the docs:

src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html
src/java.desktop/share/classes/java/awt/doc-files/Modality.html


In addition, I found several references to applets in comments. Many / most of these seem OK, but you might want to look at a few to see if you think they might worth modifying. The last two in particular might be good candidates for renaming, although that is just cosmetic at this point:


src/demo/share/jfc/J2Ddemo/java2d/RunWindow.java
src/demo/share/jfc/J2Ddemo/java2d/Tools.java
src/demo/share/jfc/SwingSet2/SwingSet2.java
src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java
test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java

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

PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960635068

From kcr at openjdk.org  Tue Jun 10 22:08:30 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Jun 2025 22:08:30 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v3]
In-Reply-To: <gmTDT8Vbf12_OO7jMgmUTNlK8wEH8Y5np2PhFFoybps=.04b234fc-c160-45f4-ae7b-fa242cd72e72@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <gmTDT8Vbf12_OO7jMgmUTNlK8wEH8Y5np2PhFFoybps=.04b234fc-c160-45f4-ae7b-fa242cd72e72@github.com>
Message-ID: <8QmPnxKuGngAFBvxSK5dnSA80ov_jWggUQ3LOgQdGGQ=.33c8c638-d602-487f-aa61-acd683a32cf7@github.com>

On Tue, 10 Jun 2025 21:28:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

One more use of java/applet that should be looked at is in `src/jdk.compiler/share/data/symbols/include.list` although I don't know whether that matters.

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

PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960689077

From prr at openjdk.org  Tue Jun 10 22:44:16 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Jun 2025 22:44:16 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v4]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <Ot0g4zk47ouROJxLmaiGkw_NIKcGVD4HvJCtJ5ukga4=.530ad58d-0f8b-4386-ad0f-d2922fcf4a6c@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/a5b4ca5e..0b5235e9

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

  Stats: 41 lines in 6 files changed: 0 ins; 33 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698

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

From kcr at openjdk.org  Tue Jun 10 22:52:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 10 Jun 2025 22:52:29 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v4]
In-Reply-To: <Ot0g4zk47ouROJxLmaiGkw_NIKcGVD4HvJCtJ5ukga4=.530ad58d-0f8b-4386-ad0f-d2922fcf4a6c@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Ot0g4zk47ouROJxLmaiGkw_NIKcGVD4HvJCtJ5ukga4=.530ad58d-0f8b-4386-ad0f-d2922fcf4a6c@github.com>
Message-ID: <Nx_xB9ITMf8i4mV8BzuHeajj28OOmFGwxV1jj3WpGho=.0ad3cb4a-72b8-4b19-b22f-d46cbbe6ff97@github.com>

On Tue, 10 Jun 2025 22:44:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

All looks good to me. I didn't build / look at the generated docs.

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2915211163

From prr at openjdk.org  Tue Jun 10 22:52:30 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Jun 2025 22:52:30 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v3]
In-Reply-To: <HTOayx0_fQogqBWm40f0qcXh74rVTPFXwlq7-e7rhRs=.4c3bb37b-65fd-459b-9d70-bfabb67dc39d@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <gmTDT8Vbf12_OO7jMgmUTNlK8wEH8Y5np2PhFFoybps=.04b234fc-c160-45f4-ae7b-fa242cd72e72@github.com>
 <HTOayx0_fQogqBWm40f0qcXh74rVTPFXwlq7-e7rhRs=.4c3bb37b-65fd-459b-9d70-bfabb67dc39d@github.com>
Message-ID: <ChHunyqjzMIn4C0_K39_7eH7E4WNonD8Vr6jenESmAk=.845e7f35-2125-4078-934c-4cfffa7b3009@github.com>

On Tue, 10 Jun 2025 21:33:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The following files still reference the now-removed applet classes and will fail to compile. Are they not included in any tier testing?
>
> ```
> test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java
> test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphPanel.java
> test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/layout.java

I didn't notice those. It can't be run by any standard task.
TEST.groups has it under
# Just-In-Time compiler tests
vmTestbase_vm_compiler = \
  vmTestbase/vm/compiler \
  vmTestbase/jit \
  vmTestbase/vm/jit

but I can't find anything that runs vmTestbase_vm_compiler
Also it is HEADFUL and no hotspot tests run today in such a mode.
So I am sure it isn't run on a regular basis. I'll file a hotspot bug on this, but first
I'll ask if anyone knows about it.

> test/jdk/java/beans/Performance/TestIntrospector.java

That was on "my list" at some point - I lost it ! I will update it.

> ```
>
> The following javadoc tests reference the java.applet package. I don't know whether or not this will cause test failures:
>
> ```
> test/langtools/jdk/javadoc/doclet/JavascriptWinTitle/package-list
> test/langtools/jdk/javadoc/doclet/testLinkOption/jdk/package-list
> test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list


These tests are run in tier1. They don't really use the applet api. They just have some data
in the test directory that they work on that lists java.applet as a package name.

The tests pass so I don't think I need to do anything, but it is probably still worth filing a bug to
see if the owners want to remove applet from the package-list


> ```
>
> The following refer to applets in API documentation, so you might consider updating the docs:
>
> ```
> src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html
> src/java.desktop/share/classes/java/awt/doc-files/Modality.html

Will do.

> ```
>
> In addition, I found several references to applets in comments. Many / most of these seem OK, but you might want to look at a few to see if you think they might worth modifying. The last two in particular might be good candidates for renaming, although that is just cosmetic at this point:
>
> ```
> src/demo/share/jfc/J2Ddemo/java2d/RunWindow.java
> src/demo/share/jfc/J2Ddemo/java2d/Tools.java
> src/demo/share/jfc/SwingSet2/SwingSet2.java
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
> test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java
> test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java
> ```

I know about the last 3 and left them.

The demos previously had applet options removed. Some comments must have been missed
I will update.

> One more use of java/applet that should be looked at is in `src/jdk.compiler/share/data/symbols/include.list` although I don't know whether that matters.

I saw that one. It wasn't clear to me how it was used, and since I didn't see any test failures I left it.
Another one to file a component team bug about.

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

PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960752780
PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2960755451

From jlu at openjdk.org  Wed Jun 11 07:49:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 07:49:29 GMT
Subject: <i18n dev> RFR: 8358819: The first year is not displayed
 correctly in Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <9SlpSwJRk_-ykaByQT771ZeFCvFXWsvdnex127x31_w=.5dde6765-5366-425c-a425-d67e2e57b4fe@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

OK, I think I understand the general idea. Japanese Imperial Calendar only returns ? for first year display name when the style is LONG.


// "GanNen" is supported only in the LONG style.
if (field == YEAR
    && (getBaseStyle(style) != LONG || fieldValue != 1 || get(ERA) == 0)) {
    return null;
}


Thus, when `SimpleDateFormat`s rely on the underlying Japanese Calendar, they fetch incorrect results since their CLDR pattern defaults to "y" for LONG and FULL, unlike COMPAT which was "yyyy".

So we are updating the CLDRConverter to adapt the old COMPAT style pattern: "yyyy" when using Japanese calendar for LONG or FULL `SimpleDateFormat` patterns, such that it can replicate the old "gannen" style which emits the ?.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25732#pullrequestreview-2916023605
PR Review: https://git.openjdk.org/jdk/pull/25732#pullrequestreview-2916024618

From joehw at openjdk.org  Wed Jun 11 16:02:27 2025
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 11 Jun 2025 16:02:27 GMT
Subject: <i18n dev> RFR: 8358819: The first year is not displayed
 correctly in Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <8m4PUpNUOMs2rbKcqJHazmWEdWfTgJvmYGeTXY66QR4=.560130ed-9050-4570-8e3f-a414b85e0229@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25732#pullrequestreview-2917827987

From naoto at openjdk.org  Wed Jun 11 16:06:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Jun 2025 16:06:40 GMT
Subject: <i18n dev> RFR: 8358734: Remove JavaTimeSupplementary resource
 bundles [v2]
In-Reply-To: <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
 <kRO9lKme-BOQIoSmwUMSzvzg4PMUvrLQ88kXUsBT1LY=.563985ed-8111-4136-a9f0-f589d534108a@github.com>
Message-ID: <Yt_KRdsimBaJrGR7qEGyaHtRhM_mZme2el-Om6LD8xQ=.9430597c-4aa4-4269-97b3-0e326748a5cc@github.com>

On Mon, 9 Jun 2025 20:07:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the bundle

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25699#issuecomment-2963386589

From naoto at openjdk.org  Wed Jun 11 16:06:40 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Jun 2025 16:06:40 GMT
Subject: <i18n dev> Integrated: 8358734: Remove JavaTimeSupplementary
 resource bundles
In-Reply-To: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
References: <sG79AHRcuj7VHF0x6la6SEQfPa3j7fkSQsLAZeI4j98=.f51e275b-f02f-4daf-afc0-c1b4a694fe95@github.com>
Message-ID: <dsQ2hgsAnMnxjrv3_TG0356h1X6hYyvaaI9ObE6cV78=.19a09ca2-2e88-447b-9612-e0578402b2a0@github.com>

On Mon, 9 Jun 2025 19:04:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The parallel loading of JavaTimeSupplementary was a historical artifact from the introduction of JSR 310, which additionally loads resouces that had not existed before. Since the COMPAT locale provider which relied on this mechanism has been removed, and the CLDR resource bundles now include those resources by default, removing the parallel loading mechanism simplifies the implementation

This pull request has now been integrated.

Changeset: e9216efe
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9216efefc12b04c372a0a7f47167c984be544b7
Stats:     1093 lines in 11 files changed: 263 ins; 792 del; 38 mod

8358734: Remove JavaTimeSupplementary resource bundles

Reviewed-by: jlu, joehw, iris

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

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

From naoto at openjdk.org  Wed Jun 11 16:13:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Jun 2025 16:13:32 GMT
Subject: <i18n dev> RFR: 8358819: The first year is not displayed
 correctly in Japanese Calendar
In-Reply-To: <9SlpSwJRk_-ykaByQT771ZeFCvFXWsvdnex127x31_w=.5dde6765-5366-425c-a425-d67e2e57b4fe@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
 <9SlpSwJRk_-ykaByQT771ZeFCvFXWsvdnex127x31_w=.5dde6765-5366-425c-a425-d67e2e57b4fe@github.com>
Message-ID: <-T2XZBJMsg_Vje6yi-FbXkAwXf5LNxezXirf4adYAvw=.6675e4e0-99cb-4331-810e-7376d515dd5c@github.com>

On Wed, 11 Jun 2025 07:46:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

> So we are updating the CLDRConverter to adapt the old COMPAT style pattern: "yyyy" when using Japanese calendar for LONG or FULL `SimpleDateFormat` patterns, such that it can replicate the old "gannen" style which emits the ?.

Yes, that?s correct. The patterns used in CLDR, SimpleDateFormat, and DateTimeFormatterBuilder are similar, but there are some differences that can be quite a pain. CLDRConverter tries to handle these differences, but I don?t think it?s entirely accurate. This case falls into that category.

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

PR Comment: https://git.openjdk.org/jdk/pull/25732#issuecomment-2963411259

From iris at openjdk.org  Wed Jun 11 17:47:29 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 11 Jun 2025 17:47:29 GMT
Subject: <i18n dev> RFR: 8358819: The first year is not displayed
 correctly in Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <tc36KXewrRNJeCnGED9Tfg5JT9IhDY8Xw9XFb9FJf7M=.83fd1338-eb53-4ac9-b442-cd4e24b40063@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25732#pullrequestreview-2918162430

From prr at openjdk.org  Wed Jun 11 18:42:22 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Jun 2025 18:42:22 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v5]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <DVV2VFRvJLtu10QX7hn8bROIX4NvMHlB026w5nx5rJU=.42bc8f87-18ef-497d-b962-b5d14bdb0c84@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/0b5235e9..ed610209

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

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

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

From prr at openjdk.org  Wed Jun 11 18:42:22 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Jun 2025 18:42:22 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v3]
In-Reply-To: <ChHunyqjzMIn4C0_K39_7eH7E4WNonD8Vr6jenESmAk=.845e7f35-2125-4078-934c-4cfffa7b3009@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <gmTDT8Vbf12_OO7jMgmUTNlK8wEH8Y5np2PhFFoybps=.04b234fc-c160-45f4-ae7b-fa242cd72e72@github.com>
 <HTOayx0_fQogqBWm40f0qcXh74rVTPFXwlq7-e7rhRs=.4c3bb37b-65fd-459b-9d70-bfabb67dc39d@github.com>
 <ChHunyqjzMIn4C0_K39_7eH7E4WNonD8Vr6jenESmAk=.845e7f35-2125-4078-934c-4cfffa7b3009@github.com>
Message-ID: <VtSsCVoJnIU0TiaooenslF_hQvjc4JMbL8v9ybIOzFM=.e2ffde87-b708-4f24-aaba-5a5abf7c60af@github.com>

On Tue, 10 Jun 2025 22:47:21 GMT, Phil Race <prr at openjdk.org> wrote:

> > The following files still reference the now-removed applet classes and will fail to compile. Are they not included in any tier testing?
> > ```
> > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java
> > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphPanel.java
> > test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/layout.java
> > ```
> 
> I didn't notice those. It can't be run by any standard task. TEST.groups has it under

It isn't run because it is marked headful and hotspot excludes headful tests.
Not sure it is ever run and probably is not adding value.
After some off-line discussion with the hotspot lead, I will remove this test as part of this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2963811726

From prr at openjdk.org  Wed Jun 11 19:18:15 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Jun 2025 19:18:15 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/ed610209..27c6eebd

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

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

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

From serb at openjdk.org  Wed Jun 11 19:24:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jun 2025 19:24:33 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
Message-ID: <gkhKPRD50y1QqzchhQ_qwFGpGGImmtVhk39DiQnm5ac=.1d0aabdd-2cdf-4146-8f79-90a265460c72@github.com>

On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

src/java.desktop/share/classes/java/awt/Window.java line 3864:

> 3862:                 content.setOpaque(isOpaque);
> 3863: 
> 3864:                 // Iterate down one level to see whether we have (eg) a JInternalFrame

I think it is more related to top level windows like JWindow/JDialog etc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140906732

From serb at openjdk.org  Wed Jun 11 19:30:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jun 2025 19:30:33 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
Message-ID: <yvmJO_9RIhBTT82Y-aIm7tsYD-r7pyi3xQGQyvxsI-g=.eb78ad72-13a7-4c5f-83e7-3f7d47f074c3@github.com>

On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 113:

> 111:      * registry functions.
> 112:      *
> 113:      * <p> Each {@code ThreadGroup} will receive its own instance.

Note that this new specification is not tied to AppContext. Do we still want to support ThreadGroup sandboxing even if AppContext will be removed? Can we drop it now, since current spec clearly tied to applets and AppContext usage?

src/java.desktop/share/classes/javax/swing/BufferStrategyPaintManager.java line 796:

> 794:             BufferStrategy bs = null;
> 795:             try {
> 796:                 ((Window)root).createBufferStrategy(2, caps);

We probably can change the type of "root" to "Window".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140913064
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140914921

From serb at openjdk.org  Wed Jun 11 19:34:31 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jun 2025 19:34:31 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
Message-ID: <L2uCL8RGYC5Hv36iOICvFoZB_2JhBU5tPtiSPJh9HdE=.bd08cfc7-3c37-4f4b-b959-152b0d802a95@github.com>

On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1656:

> 1654:      * @return the first ancestor of c that's a Window
> 1655:      */
> 1656:     @SuppressWarnings("removal")

@SuppressWarnings("removal") can be deleted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140920183

From serb at openjdk.org  Wed Jun 11 19:40:36 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jun 2025 19:40:36 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
Message-ID: <Sv6zS_jaP8wt6B9sR6_44L_n6WRMFtqWvshIS8jvCF4=.0f473458-7c88-4e5f-b5ed-3a1f4c47272c@github.com>

On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java line 33:

> 31:  * @library /vmTestbase
> 32:  *          /test/lib
> 33:  * @run main/othervm jit.misctests.fpustack.GraphApplet

Why do we delete this test? it is better to update it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140929171

From serb at openjdk.org  Wed Jun 11 19:45:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jun 2025 19:45:38 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
Message-ID: <X4wDQtk-lBCm3cwvsOEVYa8uI66MTLLLd3EQB6nflgg=.ec380d4a-8003-43ff-80d0-0f86a1a6d7d4@github.com>

On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 44:

> 42:  * @bug 8202264
> 43:  */
> 44: public final class AutoCloseTimeCheck {

This test should be updated to use SoundClip instead.

test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 48:

> 46: public class DataPusherThreadCheck {
> 47: 
> 48:     public static void main(String[] args) throws Exception {

This test should be updated to use SoundClip instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140936074
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140936963

From serb at openjdk.org  Wed Jun 11 19:49:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 11 Jun 2025 19:49:32 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
Message-ID: <akTvuHlf_eK-aTj_wRRrXMwcPWfosZwo7yYDYUw1Lgc=.7518a097-4f34-4523-88c2-8d7039c45632@github.com>

On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 51:

> 49:  * @run main/othervm -Xmx128m AudioContentHandlers
> 50:  */
> 51: public final class AudioContentHandlers {

I see the src/java.desktop/share/classes/sun/awt/www/content/audio/ are not updated, so what will be the replacement of AudioClip? I guess we should return SoundClip now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2140942251

From achung at openjdk.org  Wed Jun 11 20:58:32 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 11 Jun 2025 20:58:32 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
Message-ID: <hxYadCSLcdscaQcde5V8P62YUHWynJhaN2TInYq01yE=.115dcc42-eb1a-4379-87e9-5e5a35430b0d@github.com>

On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

Marked as reviewed by achung (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2918694517

From jlu at openjdk.org  Wed Jun 11 23:54:30 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 23:54:30 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v3]
In-Reply-To: <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
Message-ID: <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>

On Tue, 10 Jun 2025 15:41:47 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
>> 
>> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
>> 
>> Testing:
>> - GHA
>> - Local run of tier 2 and jtreg:jdk/java/text
>> - New benchmark: DecimalFormatParseBench
>
> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

On our CI, I did a java_text JCK run as well as tiers 1-3 on all platforms which both came back good. I just have a final comment.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:

> 1839: 
> 1840:     static ASCIIToBinaryConverter readDoubleSignlessDigits(int decExp, char[] digits, int length) {
> 1841:         if (decExp < MIN_DECIMAL_EXPONENT) {

Is this check needed? I think `ASCIIToBinaryConverter` will return the proper zero value when `doubleValue()` is invoked. 


  if (decExponent < MIN_DECIMAL_EXPONENT - 1) {
      return (isNegative) ? -0.0 : 0.0;


And if this explicit check is a shortcut, I don't think we would need one for an edge case.

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

PR Review: https://git.openjdk.org/jdk/pull/25644#pullrequestreview-2918990809
PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2141274926

From jlu at openjdk.org  Wed Jun 11 23:54:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Jun 2025 23:54:31 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v2]
In-Reply-To: <Du9MYXbdEwDCcfImykmsIkXrXYB59O2VZwd3bH3YbNk=.c77cc3ab-5a5f-457e-9239-a23127587cf4@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <jNo1y3QVwzaJ-e2yXXZH-hFmbtRerqT4vSytEHBN2x0=.9725dfee-cd87-4739-b313-c23af309d4ea@github.com>
 <Du9MYXbdEwDCcfImykmsIkXrXYB59O2VZwd3bH3YbNk=.c77cc3ab-5a5f-457e-9239-a23127587cf4@github.com>
Message-ID: <2KakG2f6v5WErZ_1oABFztNLVjk3qu4yO0gPZhzJxE4=.8fe81659-53fb-4ff7-91ab-401296786278@github.com>

On Mon, 9 Jun 2025 23:44:20 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   catch ArithmeticException
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1848:
> 
>> 1846:             buf[i] = (byte) digits[i];
>> 1847:         }
>> 1848:         return new ASCIIToBinaryBuffer(false, decExp, buf, length);
> 
> Since `negSign` is always false, adding a _positive_ somewhere to the method name might be helpful/explicit. Although you could argue that the array parameter itself is telling enough, but one could misinterpret the char array as including a sign character.

Thanks, I think "signless" is better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2141278327

From kcr at openjdk.org  Thu Jun 12 12:17:37 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 12 Jun 2025 12:17:37 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
Message-ID: <-98ilvtpvMl9P2an6nnDN_X3rMei2hviJeHx4Pu6hPM=.1a64ab58-71ae-43ea-a826-959e2d0f0701@github.com>

On Wed, 11 Jun 2025 19:18:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

Marked as reviewed by kcr (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2920890018

From duke at openjdk.org  Thu Jun 12 15:25:19 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 12 Jun 2025 15:25:19 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v4]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <SzEeK541fLr6annFGlSdPYm1XMcAzEL1alLFc3QITdw=.58384a94-f3da-4491-aa96-b2adab34b871@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  fix overflow check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/6953dcfc..6a072873

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

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

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

From duke at openjdk.org  Thu Jun 12 15:29:33 2025
From: duke at openjdk.org (Johannes Graham)
Date: Thu, 12 Jun 2025 15:29:33 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v3]
In-Reply-To: <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
Message-ID: <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>

On Wed, 11 Jun 2025 23:47:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:
> 
>> 1839: 
>> 1840:     static ASCIIToBinaryConverter readDoubleSignlessDigits(int decExp, char[] digits, int length) {
>> 1841:         if (decExp < MIN_DECIMAL_EXPONENT) {
> 
> Is this check needed? I think `ASCIIToBinaryConverter` will return the proper zero value when `doubleValue()` is invoked. 
> 
> 
>   if (decExponent < MIN_DECIMAL_EXPONENT - 1) {
>       return (isNegative) ? -0.0 : 0.0;
> 
> 
> And if this explicit check is a shortcut, I don't think we would need one for an edge case.

Unfortunately some check is required (a test fails), but I now realize what I had was wrong. The issue is that on line 1084 (https://github.com/openjdk/jdk/pull/25644/files#diff-79e6fd549b5ec5e7f49658581beddcb07fcbb0c09ae8e1117c385b66514da6d2R1084)) exp can overflow and become positive again. I've updated the check to avoid the overflow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2143060934

From naoto at openjdk.org  Thu Jun 12 18:07:38 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 18:07:38 GMT
Subject: <i18n dev> RFR: 8358819: The first year is not displayed
 correctly in Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <f34iT2pVfpsoPi1sXUCKeftzTmxdiozeUrrPkK022SE=.40082631-d24b-481e-84ac-495f123b8dd8@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

Thanks for the reviews!

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25732#issuecomment-2967394556
PR Comment: https://git.openjdk.org/jdk/pull/25732#issuecomment-2967755497

From naoto at openjdk.org  Thu Jun 12 18:07:39 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Jun 2025 18:07:39 GMT
Subject: <i18n dev> Integrated: 8358819: The first year is not displayed
 correctly in Japanese Calendar
In-Reply-To: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
References: <4A2N0I9S_bOoIyRQ7Qwoaz5n518LsGkBcFQZZ6NVmmM=.67acdaab-55a0-4ff4-b732-c8d0edf7b14f@github.com>
Message-ID: <vi_9s0lZdEAWy12_AOWN6UwJD9V-S7VIT7zXDfAOVro=.b076c698-9160-4839-b177-6be00ad3daee@github.com>

On Tue, 10 Jun 2025 18:36:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This regression was introduced by the removal of the COMPAT locale provider, which partially broke support for the first year in the Japanese calendar. In the Japanese calendar system, the first year of an era should be formatted using the character "?" rather than the numeral "1". The issue arises from a difference in how pattern character lengths are interpreted between CLDR and SimpleDateFormat. The existing `JapaneseEraNameTest` has been updated to cover this fix.

This pull request has now been integrated.

Changeset: 99829950
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99829950f680936489048a1ad4ce12f166805e4d
Stats:     197 lines in 3 files changed: 120 ins; 66 del; 11 mod

8358819: The first year is not displayed correctly in Japanese Calendar

Reviewed-by: jlu, joehw, iris

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

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

From prr at openjdk.org  Thu Jun 12 21:29:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Jun 2025 21:29:52 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v7]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <S2KVv7I1_PFEaaJMYTg4cYXU5mMQYq_V8JN40HSdG_8=.797d0755-f545-4b2a-a724-bdd4d93419b8@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/27c6eebd..af967ded

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

  Stats: 24 lines in 11 files changed: 0 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25698/head:pull/25698

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

From prr at openjdk.org  Thu Jun 12 21:29:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Jun 2025 21:29:52 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <L2uCL8RGYC5Hv36iOICvFoZB_2JhBU5tPtiSPJh9HdE=.bd08cfc7-3c37-4f4b-b959-152b0d802a95@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <L2uCL8RGYC5Hv36iOICvFoZB_2JhBU5tPtiSPJh9HdE=.bd08cfc7-3c37-4f4b-b959-152b0d802a95@github.com>
Message-ID: <BIDUzlomomO3GtWPkcZlllnuG92nYhBZX1hr1_loowc=.559d4cac-638b-4430-b7dd-79b6c081c121@github.com>

On Wed, 11 Jun 2025 19:31:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1656:
> 
>> 1654:      * @return the first ancestor of c that's a Window
>> 1655:      */
>> 1656:     @SuppressWarnings("removal")
> 
> @SuppressWarnings("removal") can be deleted?

That's a very good point. I had forgotten that the JDK build does not warn about *unneeded* suppressions. Only missing ones. And all those little instanceof checks means there's a bunch of them. I'll try to spot them all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143690414

From prr at openjdk.org  Thu Jun 12 22:20:01 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Jun 2025 22:20:01 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <fyfdP5RdwDhGy5521oIXzaVdG_l3gTjD-3ml5TUc1vU=.df82f5fa-9924-4709-9ee1-fef446021ad1@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/af967ded..0e921237

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

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

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

From prr at openjdk.org  Thu Jun 12 22:37:35 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Jun 2025 22:37:35 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <gkhKPRD50y1QqzchhQ_qwFGpGGImmtVhk39DiQnm5ac=.1d0aabdd-2cdf-4146-8f79-90a265460c72@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <gkhKPRD50y1QqzchhQ_qwFGpGGImmtVhk39DiQnm5ac=.1d0aabdd-2cdf-4146-8f79-90a265460c72@github.com>
Message-ID: <Vo5MUSqUE29j39oik4WRthgVisDq7Kc7U6iy8PiCI3E=.c7ec4f7b-eaa9-496d-92e4-f4d1e9c651a6@github.com>

On Wed, 11 Jun 2025 19:22:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> src/java.desktop/share/classes/java/awt/Window.java line 3864:
> 
>> 3862:                 content.setOpaque(isOpaque);
>> 3863: 
>> 3864:                 // Iterate down one level to see whether we have (eg) a JInternalFrame
> 
> I think it is more related to top level windows like JWindow/JDialog etc.

I am not sure that's the case. I think it best to leave the comment as it is - minus mention of applet.

> src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 113:
> 
>> 111:      * registry functions.
>> 112:      *
>> 113:      * <p> Each {@code ThreadGroup} will receive its own instance.
> 
> Note that this new specification is not tied to AppContext. Do we still want to support ThreadGroup sandboxing even if AppContext will be removed? Can we drop it now, since current spec clearly tied to applets and AppContext usage?

AppContext is really a ThreadGroup so it will behave as specified.
Changing this needs to be done in a separate follow-up bug likely with a CSR-specific to ImageIO, removing the ThreadGroup support.
Not in this PR. I submitted  https://bugs.openjdk.org/browse/JDK-8359391

> src/java.desktop/share/classes/javax/swing/BufferStrategyPaintManager.java line 796:
> 
>> 794:             BufferStrategy bs = null;
>> 795:             try {
>> 796:                 ((Window)root).createBufferStrategy(2, caps);
> 
> We probably can change the type of "root" to "Window".

There would be quite a ripple effect because callers are handed a container from other methods. Adds risk I don't need here.
Seems like a possible follow-on clean up bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143723251
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143714809
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143708779

From prr at openjdk.org  Thu Jun 12 22:37:36 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Jun 2025 22:37:36 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
Message-ID: <Jddfli2MuAKKrTJ2ptbmQVAd_NbMitMp3WY8Bk_fv1I=.61bf6f4e-b36f-4fb2-bcfd-909245814af1@github.com>

On Mon, 9 Jun 2025 19:39:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> src/java.desktop/share/classes/javax/swing/JComponent.java line 4684:
> 
>> 4682: 
>> 4683:     /**
>> 4684:      * Returns the top-level ancestor of this component (either the
> 
> Suggestion:
> 
>      * Returns the top-level ancestor of this component (the
> 
> There's only one option left in the parentheses.

OK.

> src/java.desktop/share/classes/javax/swing/JRootPane.java line 51:
> 
>> 49:  * component on the host system) are shown with a heavier box. AWT components in red,
>> 50:  * Swing heavyweights in blue.
>> 51:  * The three heavyweight JFC/Swing containers ({@code JFrame}, {@code JDialog}, and
> 
> Shall we drop _?JFC?_?

Out of scope of what I need to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143700859
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143697200

From prr at openjdk.org  Thu Jun 12 22:37:38 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Jun 2025 22:37:38 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <Sv6zS_jaP8wt6B9sR6_44L_n6WRMFtqWvshIS8jvCF4=.0f473458-7c88-4e5f-b5ed-3a1f4c47272c@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <Sv6zS_jaP8wt6B9sR6_44L_n6WRMFtqWvshIS8jvCF4=.0f473458-7c88-4e5f-b5ed-3a1f4c47272c@github.com>
Message-ID: <PHCKdsw5r0y9n_c_IiRje2PXqQZdj6ZJSFagc7Ahods=.942284d4-f2c9-441c-8f6e-5cff7b11d4b5@github.com>

On Wed, 11 Jun 2025 19:38:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> test/hotspot/jtreg/vmTestbase/jit/misctests/fpustack/GraphApplet.java line 33:
> 
>> 31:  * @library /vmTestbase
>> 32:  *          /test/lib
>> 33:  * @run main/othervm jit.misctests.fpustack.GraphApplet
> 
> Why do we delete this test? it is better to update it.

I discussed this test at length with the VM team and it was their request to delete it as they do not want to invest in updating it.

It has been on the "to be deleted" list  (removal_candidates.txt) for at least 7 and likely more than 10 years and it is never run and never will be. At least not by Oracle.

> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 51:
> 
>> 49:  * @run main/othervm -Xmx128m AudioContentHandlers
>> 50:  */
>> 51: public final class AudioContentHandlers {
> 
> I see the src/java.desktop/share/classes/sun/awt/www/content/audio/ are not updated, so what will be the replacement of AudioClip? I guess we should return SoundClip now?

I looked into this when I was doing SoundClip.
What is actually returned by contract is a ContentHandler which returns an Object from its getContent() method
That Object happens to be a com.sun.media.sound.JavaSoundAudioClip which previously implemented AudioClip

This implements relationship isn't there for SoundClip, so the expectation of the test that it knows of an exported type that will actually be returned is no longer valid.

I don't think it is worth testing  that JavaSoundAudioClip is returned.

Possibly we could jsut verify that a non-null handler is returned ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143693619
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143762913

From prr at openjdk.org  Thu Jun 12 22:37:39 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 12 Jun 2025 22:37:39 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v5]
In-Reply-To: <X4wDQtk-lBCm3cwvsOEVYa8uI66MTLLLd3EQB6nflgg=.ec380d4a-8003-43ff-80d0-0f86a1a6d7d4@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <X4wDQtk-lBCm3cwvsOEVYa8uI66MTLLLd3EQB6nflgg=.ec380d4a-8003-43ff-80d0-0f86a1a6d7d4@github.com>
Message-ID: <62Mly_ZNNzq86rWPqCuHivuO3YPQeFAV33GGPAWVZ0o=.e0d63be4-65e2-4044-a05e-a8a8333bc272@github.com>

On Wed, 11 Jun 2025 19:42:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 44:
> 
>> (failed to retrieve contents of file, check the PR for context)
> This test should be updated to use SoundClip instead.

I think I can do that

> test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 48:
> 
>> (failed to retrieve contents of file, check the PR for context)
> This test should be updated to use SoundClip instead.

I think I can do that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143746596
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143741448

From serb at openjdk.org  Thu Jun 12 22:50:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jun 2025 22:50:40 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <PHCKdsw5r0y9n_c_IiRje2PXqQZdj6ZJSFagc7Ahods=.942284d4-f2c9-441c-8f6e-5cff7b11d4b5@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <Sv6zS_jaP8wt6B9sR6_44L_n6WRMFtqWvshIS8jvCF4=.0f473458-7c88-4e5f-b5ed-3a1f4c47272c@github.com>
 <PHCKdsw5r0y9n_c_IiRje2PXqQZdj6ZJSFagc7Ahods=.942284d4-f2c9-441c-8f6e-5cff7b11d4b5@github.com>
Message-ID: <lJUJXTRdr_F19v9aCsrMX3KUgoHxX1B5GxAwEG0ifx4=.1fa5ad87-3ad4-4e9a-aa20-1ca2c03ec830@github.com>

On Thu, 12 Jun 2025 22:34:51 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 51:
>> 
>>> 49:  * @run main/othervm -Xmx128m AudioContentHandlers
>>> 50:  */
>>> 51: public final class AudioContentHandlers {
>> 
>> I see the src/java.desktop/share/classes/sun/awt/www/content/audio/ are not updated, so what will be the replacement of AudioClip? I guess we should return SoundClip now?
>
> I looked into this when I was doing SoundClip.
> What is actually returned by contract is a ContentHandler which returns an Object from its getContent() method
> That Object happens to be a com.sun.media.sound.JavaSoundAudioClip which previously implemented AudioClip
> 
> This implements relationship isn't there for SoundClip, so the expectation of the test that it knows of an exported type that will actually be returned is no longer valid.
> 
> I don't think it is worth testing  that JavaSoundAudioClip is returned.
> 
> Possibly we could jsut verify that a non-null handler is returned ?

As far as I understand, this method should return something that the application can actually use. Previously, the application could access the audio data via the AudioClip interface - it wasn?t important that it was specifically implemented by JavaSoundAudioClip. Now, I believe we should return a SoundClip object, which can be created (not necessarily via the public API of the SoundClip/JavaSoundAudioClip classes).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143777885

From jlu at openjdk.org  Thu Jun 12 22:54:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Jun 2025 22:54:32 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v3]
In-Reply-To: <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
 <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
Message-ID: <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>

On Thu, 12 Jun 2025 15:26:55 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1841:
>> 
>>> 1839: 
>>> 1840:     static ASCIIToBinaryConverter readDoubleSignlessDigits(int decExp, char[] digits, int length) {
>>> 1841:         if (decExp < MIN_DECIMAL_EXPONENT) {
>> 
>> Is this check needed? I think `ASCIIToBinaryConverter` will return the proper zero value when `doubleValue()` is invoked. 
>> 
>> 
>>   if (decExponent < MIN_DECIMAL_EXPONENT - 1) {
>>       return (isNegative) ? -0.0 : 0.0;
>> 
>> 
>> And if this explicit check is a shortcut, I don't think we would need one for an edge case.
>
> Unfortunately some check is required (a test fails), but I now realize what I had was wrong. The issue is that on line 1084 (https://github.com/openjdk/jdk/pull/25644/files#diff-79e6fd549b5ec5e7f49658581beddcb07fcbb0c09ae8e1117c385b66514da6d2R1084)) exp can overflow and become positive again. I've updated the check to avoid the overflow.

Ah got it, I see your point. We would have goten underflow in `ASCIIToBinaryConverter.doubleValue()` for some extreme cases without a check. 

Is there a specific example you have that requires the switch to the newer check? Adding a comment along those lines might be helpful. Actually, I thought DigitList caps `decimalAt` to Integer.MIN/MAX, so then the first check you had would have been fine. (Maybe I am missing something?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2143781479

From serb at openjdk.org  Thu Jun 12 22:56:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jun 2025 22:56:48 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <Vo5MUSqUE29j39oik4WRthgVisDq7Kc7U6iy8PiCI3E=.c7ec4f7b-eaa9-496d-92e4-f4d1e9c651a6@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <gkhKPRD50y1QqzchhQ_qwFGpGGImmtVhk39DiQnm5ac=.1d0aabdd-2cdf-4146-8f79-90a265460c72@github.com>
 <Vo5MUSqUE29j39oik4WRthgVisDq7Kc7U6iy8PiCI3E=.c7ec4f7b-eaa9-496d-92e4-f4d1e9c651a6@github.com>
Message-ID: <5pD0bFEqR2qiBSXsKWL8cyEL1WR9crFRE1lMejNsb8g=.bb1c734c-50d1-42c9-8539-2d102c62a9fb@github.com>

On Thu, 12 Jun 2025 21:45:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java line 113:
>> 
>>> 111:      * registry functions.
>>> 112:      *
>>> 113:      * <p> Each {@code ThreadGroup} will receive its own instance.
>> 
>> Note that this new specification is not tied to AppContext. Do we still want to support ThreadGroup sandboxing even if AppContext will be removed? Can we drop it now, since current spec clearly tied to applets and AppContext usage?
>
> AppContext is really a ThreadGroup so it will behave as specified.
> Changing this needs to be done in a separate follow-up bug likely with a CSR-specific to ImageIO, removing the ThreadGroup support.
> Not in this PR. I submitted  https://bugs.openjdk.org/browse/JDK-8359391

I would like to confirm that we treat ThreadGroup based sandboxing as equivalent to AppContext based sandboxing. There are a few places where we still use ThreadGroup instead of AppContext, and I believe we can drop that usage at the same time AppContext is removed, even if the specification includes statements like "Each {@code ThreadGroup} will receive its own instance." - correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143782847

From serb at openjdk.org  Thu Jun 12 23:02:34 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jun 2025 23:02:34 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <fyfdP5RdwDhGy5521oIXzaVdG_l3gTjD-3ml5TUc1vU=.df82f5fa-9924-4709-9ee1-fef446021ad1@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <fyfdP5RdwDhGy5521oIXzaVdG_l3gTjD-3ml5TUc1vU=.df82f5fa-9924-4709-9ee1-fef446021ad1@github.com>
Message-ID: <8-clqusnI8bSSn7SkZkTJB68oBESCQ7l_ycGZOCSY80=.d5724fe6-3a08-4f75-a241-0fe916f0fa01@github.com>

On Thu, 12 Jun 2025 22:20:01 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 73:

> 71: 
> 72:     private static void checkThread(File file) throws Exception {
> 73:         SoundClip clip = SoundClip.createSoundClip(file);

I think we should either support content handlers via the new SoundClip object or remove the existing implementation, as it is currently tied to AudioClip.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143788994

From serb at openjdk.org  Thu Jun 12 23:11:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jun 2025 23:11:33 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <Vo5MUSqUE29j39oik4WRthgVisDq7Kc7U6iy8PiCI3E=.c7ec4f7b-eaa9-496d-92e4-f4d1e9c651a6@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <gkhKPRD50y1QqzchhQ_qwFGpGGImmtVhk39DiQnm5ac=.1d0aabdd-2cdf-4146-8f79-90a265460c72@github.com>
 <Vo5MUSqUE29j39oik4WRthgVisDq7Kc7U6iy8PiCI3E=.c7ec4f7b-eaa9-496d-92e4-f4d1e9c651a6@github.com>
Message-ID: <OQDeRdQTby6c1_Q4m3pqdzrwfiLCK8Ef1P54_4ngeVQ=.ef3cdb89-d174-423e-b7d4-f7bba417a160@github.com>

On Thu, 12 Jun 2025 21:54:03 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Window.java line 3864:
>> 
>>> 3862:                 content.setOpaque(isOpaque);
>>> 3863: 
>>> 3864:                 // Iterate down one level to see whether we have (eg) a JInternalFrame
>> 
>> I think it is more related to top level windows like JWindow/JDialog etc.
>
> I am not sure that's the case. I think it best to leave the comment as it is - minus mention of applet.

After the applet removal, this could be dead code. It might be better not to mention JInternalFrame unless we have prove that the code actually works for it, add a TODO? or something?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143797148

From serb at openjdk.org  Thu Jun 12 23:11:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 12 Jun 2025 23:11:33 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <OQDeRdQTby6c1_Q4m3pqdzrwfiLCK8Ef1P54_4ngeVQ=.ef3cdb89-d174-423e-b7d4-f7bba417a160@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <gkhKPRD50y1QqzchhQ_qwFGpGGImmtVhk39DiQnm5ac=.1d0aabdd-2cdf-4146-8f79-90a265460c72@github.com>
 <Vo5MUSqUE29j39oik4WRthgVisDq7Kc7U6iy8PiCI3E=.c7ec4f7b-eaa9-496d-92e4-f4d1e9c651a6@github.com>
 <OQDeRdQTby6c1_Q4m3pqdzrwfiLCK8Ef1P54_4ngeVQ=.ef3cdb89-d174-423e-b7d4-f7bba417a160@github.com>
Message-ID: <HRhSIPCw_IxpMFUrF43-Ks_UPGBEOxZjVMqijHAAAZg=.30583a5d-9531-4c29-a375-1802b0a7efb8@github.com>

On Thu, 12 Jun 2025 23:06:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I am not sure that's the case. I think it best to leave the comment as it is - minus mention of applet.
>
> After the applet removal, this could be dead code. It might be better not to mention JInternalFrame unless we have prove that the code actually works for it, add a TODO? or something?

it could be related to appletviewer

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2143798449

From ihse at openjdk.org  Fri Jun 13 13:52:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 13 Jun 2025 13:52:39 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <BIDUzlomomO3GtWPkcZlllnuG92nYhBZX1hr1_loowc=.559d4cac-638b-4430-b7dd-79b6c081c121@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <L2uCL8RGYC5Hv36iOICvFoZB_2JhBU5tPtiSPJh9HdE=.bd08cfc7-3c37-4f4b-b959-152b0d802a95@github.com>
 <BIDUzlomomO3GtWPkcZlllnuG92nYhBZX1hr1_loowc=.559d4cac-638b-4430-b7dd-79b6c081c121@github.com>
Message-ID: <NixgwkPQxUS31xznaQqzhUi_DxvYOr3aGctpSeCNj0E=.352850f0-daca-42d4-9463-b9e319c600c5@github.com>

On Thu, 12 Jun 2025 21:25:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 1656:
>> 
>>> 1654:      * @return the first ancestor of c that's a Window
>>> 1655:      */
>>> 1656:     @SuppressWarnings("removal")
>> 
>> @SuppressWarnings("removal") can be deleted?
>
> That's a very good point. I had forgotten that the JDK build does not warn about *unneeded* suppressions. Only missing ones. And all those little instanceof checks means there's a bunch of them. I'll try to spot them all.

I wish there were a way to do that, but I can't see how that could be done. At the core of the problem lies the fact that the specification of `@SuppressWarnings` does not specify what you can give as strings, and different compilers can behave differently and have any arbitrary strings. So javac cannot say "this string is invalid" or "this warning does not apply here so nothing is suppressed". Or, well, it *could* do but that but then it would complain on code that is "technically" correct. I don't think I'd be very successful in persuading the langtools team to do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2145147941

From prr at openjdk.org  Fri Jun 13 19:29:44 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Jun 2025 19:29:44 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <5pD0bFEqR2qiBSXsKWL8cyEL1WR9crFRE1lMejNsb8g=.bb1c734c-50d1-42c9-8539-2d102c62a9fb@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <gkhKPRD50y1QqzchhQ_qwFGpGGImmtVhk39DiQnm5ac=.1d0aabdd-2cdf-4146-8f79-90a265460c72@github.com>
 <Vo5MUSqUE29j39oik4WRthgVisDq7Kc7U6iy8PiCI3E=.c7ec4f7b-eaa9-496d-92e4-f4d1e9c651a6@github.com>
 <5pD0bFEqR2qiBSXsKWL8cyEL1WR9crFRE1lMejNsb8g=.bb1c734c-50d1-42c9-8539-2d102c62a9fb@github.com>
Message-ID: <QC4rzEwM1GDLJzIseNyqRGxTVAhxipQfCQpYqjavN48=.b50f8d86-df53-4ab8-9542-c2a843ddd7fb@github.com>

On Thu, 12 Jun 2025 22:54:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I would like to confirm that we treat ThreadGroup based sandboxing as equivalent to AppContext based sandboxing. There are a few places where we still use ThreadGroup instead of AppContext, and I believe we can drop that usage at the same time AppContext is removed, even if the specification includes statements like "Each {@code ThreadGroup} will receive its own instance." - correct?

I *think* that is true. The word/name AppContext probably should never be in API doc and saying  ThreadGroup is a decent substitute, but wherever we did either of these for the sake of applet partitioning they can probably all go away. I hope spec. appearances are rare.
Eliminating AppContext is going to be a good size piece by piece project even without that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2145928751

From duke at openjdk.org  Fri Jun 13 19:33:18 2025
From: duke at openjdk.org (Johannes Graham)
Date: Fri, 13 Jun 2025 19:33:18 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v5]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <Ak8ex7_jSxy75IEIdfCBSeZh2qd103F5--f3s4h_Gho=.aa54d788-a687-49fa-bb35-a14871af7f40@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  Revert "fix overflow check"
  
  This reverts commit 6a072873ffa87d1191b42053b9f5d955f0119057.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/6a072873..c87a3ded

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

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

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

From duke at openjdk.org  Fri Jun 13 19:37:32 2025
From: duke at openjdk.org (Johannes Graham)
Date: Fri, 13 Jun 2025 19:37:32 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v3]
In-Reply-To: <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
 <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
 <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>
Message-ID: <hzCwNHUbtMWh_V3rtnMipAOj2_bB1UF-Sewy2kttvH4=.d29dac97-b7df-4a17-94ff-36c4ce8cbed1@github.com>

On Thu, 12 Jun 2025 22:52:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Unfortunately some check is required (a test fails), but I now realize what I had was wrong. The issue is that on line 1084 (https://github.com/openjdk/jdk/pull/25644/files#diff-79e6fd549b5ec5e7f49658581beddcb07fcbb0c09ae8e1117c385b66514da6d2R1084)) exp can overflow and become positive again. I've updated the check to avoid the overflow.
>
> Ah got it, I see your point. We would have goten underflow in `ASCIIToBinaryConverter.doubleValue()` for some extreme cases without a check. 
> 
> Is there a specific example you have that requires the switch to the newer check? Adding a comment along those lines might be helpful. Actually, I thought DigitList caps `decimalAt` to Integer.MIN/MAX, so then the first check you had would have been fine. (Maybe I am missing something?)

I don't have a specific example, so I've reverted to my original check. I'm a bit unsettled by the check for an extreme value later in `doubleValue()` comparing against `MIN_DECIMAL_EXPONENT - 1`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2145942325

From prr at openjdk.org  Fri Jun 13 20:02:43 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Jun 2025 20:02:43 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v6]
In-Reply-To: <HRhSIPCw_IxpMFUrF43-Ks_UPGBEOxZjVMqijHAAAZg=.30583a5d-9531-4c29-a375-1802b0a7efb8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <gkhKPRD50y1QqzchhQ_qwFGpGGImmtVhk39DiQnm5ac=.1d0aabdd-2cdf-4146-8f79-90a265460c72@github.com>
 <Vo5MUSqUE29j39oik4WRthgVisDq7Kc7U6iy8PiCI3E=.c7ec4f7b-eaa9-496d-92e4-f4d1e9c651a6@github.com>
 <OQDeRdQTby6c1_Q4m3pqdzrwfiLCK8Ef1P54_4ngeVQ=.ef3cdb89-d174-423e-b7d4-f7bba417a160@github.com>
 <HRhSIPCw_IxpMFUrF43-Ks_UPGBEOxZjVMqijHAAAZg=.30583a5d-9531-4c29-a375-1802b0a7efb8@github.com>
Message-ID: <azHYQU2oZ4K5kNzVtRhLA_dXqn56NgZYbY5JX7EAdv0=.4a427911-4f8a-427d-990d-650369606b45@github.com>

On Thu, 12 Jun 2025 23:08:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> After the applet removal, this could be dead code. It might be better not to mention JInternalFrame unless we have prove that the code actually works for it, add a TODO? or something?
>
> it could be related to appletviewer

Unlikely. JInternalFrame is a RootPaneContainer and validate root. It has a  set size and stuff resized within it do NOT make the containing Container revalidate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2145955172

From prr at openjdk.org  Fri Jun 13 20:02:43 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Jun 2025 20:02:43 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <8-clqusnI8bSSn7SkZkTJB68oBESCQ7l_ycGZOCSY80=.d5724fe6-3a08-4f75-a241-0fe916f0fa01@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <fyfdP5RdwDhGy5521oIXzaVdG_l3gTjD-3ml5TUc1vU=.df82f5fa-9924-4709-9ee1-fef446021ad1@github.com>
 <8-clqusnI8bSSn7SkZkTJB68oBESCQ7l_ycGZOCSY80=.d5724fe6-3a08-4f75-a241-0fe916f0fa01@github.com>
Message-ID: <xNJgy6muoDICWHhpi3g4uVoA-1cmX6sttCqbPoq1Lcc=.236b915c-8c88-4fc3-a9d1-42e02dc8f7f2@github.com>

On Thu, 12 Jun 2025 23:00:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 73:
> 
>> 71: 
>> 72:     private static void checkThread(File file) throws Exception {
>> 73:         SoundClip clip = SoundClip.createSoundClip(file);
> 
> I think we should either support content handlers via the new SoundClip object or remove the existing implementation, as it is currently tied to AudioClip.

was this comment meant to be on some other (test) code ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146001842

From serb at openjdk.org  Fri Jun 13 20:20:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 13 Jun 2025 20:20:33 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <xNJgy6muoDICWHhpi3g4uVoA-1cmX6sttCqbPoq1Lcc=.236b915c-8c88-4fc3-a9d1-42e02dc8f7f2@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <fyfdP5RdwDhGy5521oIXzaVdG_l3gTjD-3ml5TUc1vU=.df82f5fa-9924-4709-9ee1-fef446021ad1@github.com>
 <8-clqusnI8bSSn7SkZkTJB68oBESCQ7l_ycGZOCSY80=.d5724fe6-3a08-4f75-a241-0fe916f0fa01@github.com>
 <xNJgy6muoDICWHhpi3g4uVoA-1cmX6sttCqbPoq1Lcc=.236b915c-8c88-4fc3-a9d1-42e02dc8f7f2@github.com>
Message-ID: <kjdFIhhwrmUA7lekJjDkCl3Hh7xCz_BhSt2XiVxaatg=.f5a4f132-be8d-424f-a6a6-26a1cb22bdaa@github.com>

On Fri, 13 Jun 2025 19:59:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 73:
>> 
>>> 71: 
>>> 72:     private static void checkThread(File file) throws Exception {
>>> 73:         SoundClip clip = SoundClip.createSoundClip(file);
>> 
>> I think we should either support content handlers via the new SoundClip object or remove the existing implementation, as it is currently tied to AudioClip.
>
> was this comment meant to be on some other (test) code ?

It is about content handlers we discussed above and its implementation in awt/www/content/audio/. If we want to support content handlers then it is not necessary to change this in the test:
>SoundClip clip = (SoundClip) file.toURL().getContent();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146024244

From prr at openjdk.org  Fri Jun 13 21:53:33 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 13 Jun 2025 21:53:33 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <lJUJXTRdr_F19v9aCsrMX3KUgoHxX1B5GxAwEG0ifx4=.1fa5ad87-3ad4-4e9a-aa20-1ca2c03ec830@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <Sv6zS_jaP8wt6B9sR6_44L_n6WRMFtqWvshIS8jvCF4=.0f473458-7c88-4e5f-b5ed-3a1f4c47272c@github.com>
 <PHCKdsw5r0y9n_c_IiRje2PXqQZdj6ZJSFagc7Ahods=.942284d4-f2c9-441c-8f6e-5cff7b11d4b5@github.com>
 <lJUJXTRdr_F19v9aCsrMX3KUgoHxX1B5GxAwEG0ifx4=.1fa5ad87-3ad4-4e9a-aa20-1ca2c03ec830@github.com>
Message-ID: <oLZZgguiy_GVWSDDsbo6zC69HorizSaa2IUF8hsKcrM=.59428ebe-0aa0-4eb8-a960-614f0d5baf1a@github.com>

On Thu, 12 Jun 2025 22:48:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I looked into this when I was doing SoundClip.
>> What is actually returned by contract is a ContentHandler which returns an Object from its getContent() method
>> That Object happens to be a com.sun.media.sound.JavaSoundAudioClip which previously implemented AudioClip
>> 
>> This implements relationship isn't there for SoundClip, so the expectation of the test that it knows of an exported type that will actually be returned is no longer valid.
>> 
>> I don't think it is worth testing  that JavaSoundAudioClip is returned.
>> 
>> Possibly we could jsut verify that a non-null handler is returned ?
>
> As far as I understand, this method should return something that the application can actually use. Previously, the application could access the audio data via the AudioClip interface - it wasn?t important that it was specifically implemented by JavaSoundAudioClip. Now, I believe we should return a SoundClip object, which can be created (not necessarily via the public API of the SoundClip/JavaSoundAudioClip classes).

I have no idea how applications (or applets) could really have used this URL.getContent() API that just returns an Object.
It seems like it was meant to be used by some other part of the larger JDK that was aware of how this was implemented.
I am inclined to ask the networking API owners what the purpose and future should be.
I also don't particularly like the java.base module (even via this private SPI) calling into the desktop module. 
When the desktop module isn't present in a jlinked image it will not find a handler and have to do some default thing such as return raw bytes or null.

So I can probably return a SoundClip but any code out there that used this was always taking a chance. OTOH we are removing Applet entirely so anyone who was relying on this is out of luck anyway.

>> was this comment meant to be on some other (test) code ?
>
> It is about content handlers we discussed above and its implementation in awt/www/content/audio/. If we want to support content handlers then it is not necessary to change this in the test:
>>SoundClip clip = (SoundClip) file.toURL().getContent();

Not sure I would do that anyway here. It seems like an unnecessary file->url->file roundtrip with a cast to a type you have to "know". And it was never specified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146175203
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2146141458

From gkrishnan at openjdk.org  Mon Jun 16 16:43:00 2025
From: gkrishnan at openjdk.org (Gautham Krishnan)
Date: Mon, 16 Jun 2025 16:43:00 GMT
Subject: <i18n dev> RFR: 8294226: Document missing
 UnsupportedTemporalTypeException
Message-ID: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>

Some methods in the java.time.chrono interfaces?ChronoLocalDate, ChronoLocalDateTime, and ChronoZonedDateTime?override methods from the java.time.temporal.Temporal interface that are documented to throw UnsupportedTemporalTypeException when given unsupported fields or units.

These overridden methods include:

with(TemporalField, long)

plus(long, TemporalUnit)

minus(long, TemporalUnit)

However, their Javadoc in the chrono interfaces does not mention the possibility of this exception, resulting in incomplete or inconsistent documentation. This contrasts with the parent Temporal interface, which explicitly documents the exception.

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

Commit messages:
 - Documenting missing UnsupportedTemporalTypeException

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

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

From rriggs at openjdk.org  Mon Jun 16 17:47:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 16 Jun 2025 17:47:28 GMT
Subject: <i18n dev> RFR: 8294226: Document missing
 UnsupportedTemporalTypeException
In-Reply-To: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
References: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
Message-ID: <DJf9iY_iNvzFr11mFO6DY8Mo2UVtv87V0dsE16v3K9I=.d30ce50d-190f-421c-9c1d-b44e88fa1aea@github.com>

On Mon, 16 Jun 2025 16:36:43 GMT, Gautham Krishnan <gkrishnan at openjdk.org> wrote:

> Some methods in the java.time.chrono interfaces?ChronoLocalDate, ChronoLocalDateTime, and ChronoZonedDateTime?override methods from the java.time.temporal.Temporal interface that are documented to throw UnsupportedTemporalTypeException when given unsupported fields or units.
> 
> These overridden methods include:
> 
> with(TemporalField, long)
> 
> plus(long, TemporalUnit)
> 
> minus(long, TemporalUnit)
> 
> However, their Javadoc in the chrono interfaces does not mention the possibility of this exception, resulting in incomplete or inconsistent documentation. This contrasts with the parent Temporal interface, which explicitly documents the exception.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25836#pullrequestreview-2932969154

From jlu at openjdk.org  Mon Jun 16 18:22:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 16 Jun 2025 18:22:31 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v3]
In-Reply-To: <hzCwNHUbtMWh_V3rtnMipAOj2_bB1UF-Sewy2kttvH4=.d29dac97-b7df-4a17-94ff-36c4ce8cbed1@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
 <-6TYWikmLNBtyQt6_xeJ8KoziHxA8Ijr067NIc740X0=.2f9e4cae-7f39-46b8-b3a9-f381fb2e0518@github.com>
 <JNEKtkhrEYnS1SvaSz7GhcS4FQGkQXma4nY_Wo0T18A=.3dce72d9-7250-4672-adad-13db79e3150c@github.com>
 <tCE4NXNXnwQro2lXxzJbDuJzrcTt3k2bNrR8wk54jX8=.6a749f99-e70b-426b-ad9d-e077c115f42d@github.com>
 <Tv8HMWAw2YxNwcjL3_8ZoELHZZHCI-RSeMNbN-NBU5g=.dac7959c-1d74-47c3-a283-fe212dcd3705@github.com>
 <hzCwNHUbtMWh_V3rtnMipAOj2_bB1UF-Sewy2kttvH4=.d29dac97-b7df-4a17-94ff-36c4ce8cbed1@github.com>
Message-ID: <vEAT8VpjJFBMyG87cz0gBcu2zwzPDOXuZWKksj_UPiw=.d2b9f24e-9411-4969-a261-e5415aa18498@github.com>

On Fri, 13 Jun 2025 19:34:40 GMT, Johannes Graham <duke at openjdk.org> wrote:

>> Ah got it, I see your point. We would have goten underflow in `ASCIIToBinaryConverter.doubleValue()` for some extreme cases without a check. 
>> 
>> Is there a specific example you have that requires the switch to the newer check? Adding a comment along those lines might be helpful. Actually, I thought DigitList caps `decimalAt` to Integer.MIN/MAX, so then the first check you had would have been fine. (Maybe I am missing something?)
>
> I don't have a specific example, so I've reverted to my original check. I'm a bit unsettled by the check for an extreme value later in `doubleValue()` comparing against `MIN_DECIMAL_EXPONENT - 1`

IMO, the original check you had is easier to understand what is happening without further context, so I prefer your switch back. 

I think we are fine from (negative) "extreme values" in `doubleValue()` because of the check you have implemented in the first place. i.e. we avoid any potential underflow from `int exp = decExponent - kDigits;`. I think we do need a comment to accompany the check. (Why do we check? why not check the max exponent value?)

Also, should the check be against `MIN_DECIMAL_EXPONENT - 1` for consistency with `doubleValue()`? (Functionally, I don't think it matters.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25644#discussion_r2150586388

From naoto at openjdk.org  Mon Jun 16 20:37:32 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Jun 2025 20:37:32 GMT
Subject: <i18n dev> RFR: 8294226: Document missing
 UnsupportedTemporalTypeException
In-Reply-To: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
References: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
Message-ID: <zvVwUWbQhHBKgssBBVkeaJpmiJUrKTbFgH3s2MJg6RQ=.0db256a4-cdb2-4c6c-8740-8115fb57eb89@github.com>

On Mon, 16 Jun 2025 16:36:43 GMT, Gautham Krishnan <gkrishnan at openjdk.org> wrote:

> Some methods in the java.time.chrono interfaces?ChronoLocalDate, ChronoLocalDateTime, and ChronoZonedDateTime?override methods from the java.time.temporal.Temporal interface that are documented to throw UnsupportedTemporalTypeException when given unsupported fields or units.
> 
> These overridden methods include:
> 
> with(TemporalField, long)
> 
> plus(long, TemporalUnit)
> 
> minus(long, TemporalUnit)
> 
> However, their Javadoc in the chrono interfaces does not mention the possibility of this exception, resulting in incomplete or inconsistent documentation. This contrasts with the parent Temporal interface, which explicitly documents the exception.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25836#pullrequestreview-2933434612

From duke at openjdk.org  Mon Jun 16 21:19:45 2025
From: duke at openjdk.org (Johannes Graham)
Date: Mon, 16 Jun 2025 21:19:45 GMT
Subject: <i18n dev> RFR: 8358880: Performance of parsing with
 DecimalFormat can be improved [v6]
In-Reply-To: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
References: <VmiaKymiukAeATovzbLtRND3Nm4du_Zqa-WpHcC27GY=.db1a3133-9089-4344-839f-91011cd050dd@github.com>
Message-ID: <JdxWpCBHtTssvz1lu08gRSrJr3So7vxoi5hiopLlxLo=.3931a767-c13c-455a-b631-616cbbd250ff@github.com>

> This PR replaces construction of intermediate strings to be parsed with more direct manipulation of numbers. It also has a more streamlined mechanism of handling `Long.MIN_VALUE` when parsing longs by using `Long.parseUnsignedLong`
> 
> As a small side-effect it also eliminates the use of a cached StringBuilder in DigitList.
> 
> Testing:
> - GHA
> - Local run of tier 2 and jtreg:jdk/java/text
> - New benchmark: DecimalFormatParseBench

Johannes Graham has updated the pull request incrementally with one additional commit since the last revision:

  add comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25644/files
  - new: https://git.openjdk.org/jdk/pull/25644/files/c87a3ded..b7faa3b8

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

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

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

From serb at openjdk.org  Tue Jun 17 03:35:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 17 Jun 2025 03:35:39 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v8]
In-Reply-To: <oLZZgguiy_GVWSDDsbo6zC69HorizSaa2IUF8hsKcrM=.59428ebe-0aa0-4eb8-a960-614f0d5baf1a@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <Sv6zS_jaP8wt6B9sR6_44L_n6WRMFtqWvshIS8jvCF4=.0f473458-7c88-4e5f-b5ed-3a1f4c47272c@github.com>
 <PHCKdsw5r0y9n_c_IiRje2PXqQZdj6ZJSFagc7Ahods=.942284d4-f2c9-441c-8f6e-5cff7b11d4b5@github.com>
 <lJUJXTRdr_F19v9aCsrMX3KUgoHxX1B5GxAwEG0ifx4=.1fa5ad87-3ad4-4e9a-aa20-1ca2c03ec830@github.com>
 <oLZZgguiy_GVWSDDsbo6zC69HorizSaa2IUF8hsKcrM=.59428ebe-0aa0-4eb8-a960-614f0d5baf1a@github.com>
Message-ID: <cv1jiCEIA1RS5ZRtOxoy9vDPDcUz0x7jxZt4kNxu-hk=.5930e7f4-e91a-4690-b3ce-188f7f5efa1b@github.com>

On Fri, 13 Jun 2025 21:51:05 GMT, Phil Race <prr at openjdk.org> wrote:

> I am inclined to ask the networking API owners what the purpose and future should be.

Yeah, that will be useful to know the future of this api, we have similar handlers for images.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2151250650

From prr at openjdk.org  Tue Jun 17 18:23:30 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jun 2025 18:23:30 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/0e921237..253d2bc0

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

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

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

From prr at openjdk.org  Tue Jun 17 19:22:38 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jun 2025 19:22:38 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <cv1jiCEIA1RS5ZRtOxoy9vDPDcUz0x7jxZt4kNxu-hk=.5930e7f4-e91a-4690-b3ce-188f7f5efa1b@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <N0bzqyvd4BXvOTLj0xOT2x58aEKNZNXI7oiu-2pCm7s=.ea0b36c7-428e-40da-aa9d-9b2d95eb1fde@github.com>
 <Sv6zS_jaP8wt6B9sR6_44L_n6WRMFtqWvshIS8jvCF4=.0f473458-7c88-4e5f-b5ed-3a1f4c47272c@github.com>
 <PHCKdsw5r0y9n_c_IiRje2PXqQZdj6ZJSFagc7Ahods=.942284d4-f2c9-441c-8f6e-5cff7b11d4b5@github.com>
 <lJUJXTRdr_F19v9aCsrMX3KUgoHxX1B5GxAwEG0ifx4=.1fa5ad87-3ad4-4e9a-aa20-1ca2c03ec830@github.com>
 <oLZZgguiy_GVWSDDsbo6zC69HorizSaa2IUF8hsKcrM=.59428ebe-0aa0-4eb8-a960-614f0d5baf1a@github.com>
 <cv1jiCEIA1RS5ZRtOxoy9vDPDcUz0x7jxZt4kNxu-hk=.5930e7f4-e91a-4690-b3ce-188f7f5efa1b@github.com>
Message-ID: <CwFmOVgGcWBBSrDJRmwu9Wa0Fyg_C2aaTfHBzPIwbzw=.c9e4680e-e978-4f60-a419-a206cafadb94@github.com>

On Tue, 17 Jun 2025 03:33:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I am inclined to ask the networking API owners what the purpose and future should be.
> 
> Yeah, that will be useful to know the future of this api, we have similar handlers for images.

Discussion here  https://mail.openjdk.org/pipermail/net-dev/2025-June/027254.html

The suggestion was to return null. That might be a long-term direction but for now I'm going with the idea to return SoundClip. It is a little more usable for migration than null.

We might some day get rid of the MultimediaContentHandlers but not here/yet
FYI:  my testing, there's nothing that relies on the audio handlers *except* for tests explicitly for these.
The image case is however used in the java.beans implementation
I submitted  https://bugs.openjdk.org/browse/JDK-8359727

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153010836

From prr at openjdk.org  Tue Jun 17 20:46:38 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 17 Jun 2025 20:46:38 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
Message-ID: <8KKHE4cyjH7CDtwpoJphiaxqqhxkYezchgwnOfXOZw0=.94a281fb-ce58-4ef2-8fdf-677399220e6b@github.com>

On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

I think I have responded to all substantial issues, and in most cases updated the PR according to the feedback.
Specification questions  that have been raised are resolved and the CSR is approved.
Unless someone identifies a new problem, I am not expecting to make any changes that would be significant to the CSR or JEP. 

So I will wait a few days to give people a chance to have a last look but I believe we are getting very close to PTT (Propose To Target) for this JEP - with the target being JDK 26.

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

PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2981779647

From aivanov at openjdk.org  Tue Jun 17 21:51:40 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 17 Jun 2025 21:51:40 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
Message-ID: <RR73kWZ5VFgmZ6c0kFWrYQsmnBkp_KQbVCV6xu3y97w=.a5b9b525-f39e-43b6-b79c-32f935245d78@github.com>

On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/com/sun/media/sound/JavaSoundAudioClip.java line 123:

> 121:         try {
> 122:              return SoundClip.createSoundClip(tmpFile);
> 123:         } catch (IOException e) {

Suggestion:

        } catch (IOException ignored) {

To explicitly document that we ignore the exception, and to avoid warnings in IDE.

src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 352:

> 350:       <code>Dialog(owner, true)</code>, etc. Prior to JDK 6
> 351:       the default type was toolkit-modal,
> 352:       and now with single application per-VM there is no

Suggestion:

      and now with single application per VM there is no

src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 353:

> 351:       the default type was toolkit-modal,
> 352:       and now with single application per-VM there is no
> 353:       distinction between application- and toolkit-modality

Suggestion:

      distinction between application- and toolkit-modality.

End the sentence with a full stop?

test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 87:

> 85:                     generateOOME();
> 86:                 } finally {
> 87:                     Files.delete(file.toPath());

Suggestion:

                    file.delete();

Other parts of the test don't use NIO.

test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 54:

> 52:             AudioSystem.write(getStream(format), Type.WAVE, file);
> 53:         } catch (final Exception ignored) {
> 54:             return; // the test is not applicable

I suggest throwing `jtreg.SkippedException`, such tests aren't handled as passed.

test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 60:

> 58:             testBigDelay(file);
> 59:         } finally {
> 60:             Files.delete(file.toPath());

Suggestion:

            file.delete();

Should work just as good.

test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java line 115:

> 113: 
> 114:     private static long count() {
> 115:         for (final Thread t : Thread.getAllStackTraces().keySet()) {

Why are stack traces are needed?


Thread[]  threads = new Thread[Thread.activeCount()];
Thread.enumerate(threads);

would give the same estimate and use less resources.

[`Thread.enumerate`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#enumerate(java.lang.Thread%5B%5D)) fills the provided array with currently active threads, and [`Thread.activeCount`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#activeCount()) provides an estimate on the number of live threads.

test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 25:

> 23: 
> 24: import static javax.sound.sampled.AudioFormat.Encoding.PCM_SIGNED;
> 25: import static javax.sound.sampled.AudioSystem.NOT_SPECIFIED;

Static imports usually follow the regular imports, and both `test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java` and `test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java` follow this convention.

And the two other tests import `java.*` packages first and then `javax.*` packages, whereas this test reverses the (common) order of imports.

test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 63:

> 61:             AudioSystem.write(audioStream, AudioFileFormat.Type.WAVE, file);
> 62:         } catch (Exception ignored) {
> 63:             return; // the test is not applicable

Throw `jtreg.SkippedException`? The test didn't run.

test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 68:

> 66:             checkThread(file);
> 67:         } finally {
> 68:             Files.delete(file.toPath());

Suggestion:

            file.delete();

test/jdk/javax/sound/sampled/Clip/DataPusherThreadCheck.java line 87:

> 85: 
> 86:     private static boolean isDataPushedThreadExist() {
> 87:         for (Thread t : Thread.getAllStackTraces().keySet()) {

Can [Thread.enumerate](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#enumerate(java.lang.Thread%5B%5D)) be used instead?

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2937108877
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153180466
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153183860
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153183390
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153193516
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153196462
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153198451
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153218422
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153222545
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153223792
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153223055
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153226754

From serb at openjdk.org  Wed Jun 18 02:42:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Jun 2025 02:42:40 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <RR73kWZ5VFgmZ6c0kFWrYQsmnBkp_KQbVCV6xu3y97w=.a5b9b525-f39e-43b6-b79c-32f935245d78@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
 <RR73kWZ5VFgmZ6c0kFWrYQsmnBkp_KQbVCV6xu3y97w=.a5b9b525-f39e-43b6-b79c-32f935245d78@github.com>
Message-ID: <KFT4-IAWKgN850_Vj1brqDSuDx8mXOx2A2EZQmE6yCk=.8f12020e-754b-48fa-894e-14dd39c61073@github.com>

On Tue, 17 Jun 2025 21:24:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> test/jdk/javax/sound/sampled/Clip/AudioContentHandlers.java line 87:
> 
>> 85:                     generateOOME();
>> 86:                 } finally {
>> 87:                     Files.delete(file.toPath());
> 
> Suggestion:
> 
>                     file.delete();
> 
> Other parts of the test don't use NIO.

it is done intentionally to throw an exception if the file is locked.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2153520113

From serb at openjdk.org  Wed Jun 18 09:56:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 18 Jun 2025 09:56:37 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
Message-ID: <rv__WJfLFyesm3VfeF4a48bp3LWL2muyEvdXFZ46I6k=.27a3b63d-bd28-421e-904b-5c43118d230b@github.com>

On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2938561283

From aivanov at openjdk.org  Wed Jun 18 14:07:38 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 14:07:38 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <KFT4-IAWKgN850_Vj1brqDSuDx8mXOx2A2EZQmE6yCk=.8f12020e-754b-48fa-894e-14dd39c61073@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
 <RR73kWZ5VFgmZ6c0kFWrYQsmnBkp_KQbVCV6xu3y97w=.a5b9b525-f39e-43b6-b79c-32f935245d78@github.com>
 <KFT4-IAWKgN850_Vj1brqDSuDx8mXOx2A2EZQmE6yCk=.8f12020e-754b-48fa-894e-14dd39c61073@github.com>
Message-ID: <HTPtpm4AWzSW4rDqChXevLm1OiwI9Ts-MVI0Y0vTVDg=.726c4c25-5604-447b-9723-7f1f3b8a47a1@github.com>

On Wed, 18 Jun 2025 02:39:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> it is done intentionally to throw an exception if the file is locked.

A comment would've clarified the intention.

This also means that if the test fails for whatever reason and `Files.delete` throws the exception, the original exception gets replaced with `IOException` from deleting the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2154701920

From aivanov at openjdk.org  Wed Jun 18 14:19:41 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 14:19:41 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
Message-ID: <p2wM1W_vbDz4VcmeFg_gF0lQTSXabOjY37C7dH2jupY=.de183af8-0147-46b0-8bd3-ab0aee2532e0@github.com>

On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 353:

> 351:       the default type was toolkit-modal,
> 352:       and now with single application per-VM there is no
> 353:       distinction between application- and toolkit-modality

Suggestion:

      and now with single application per VM there is no
      distinction between application- and toolkit-modality.

There should be a space between a preposition and a noun and a full stop in the end of the sentence.

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2939418360
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2154723332

From aivanov at openjdk.org  Wed Jun 18 14:19:42 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 14:19:42 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <8KKHE4cyjH7CDtwpoJphiaxqqhxkYezchgwnOfXOZw0=.94a281fb-ce58-4ef2-8fdf-677399220e6b@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
 <8KKHE4cyjH7CDtwpoJphiaxqqhxkYezchgwnOfXOZw0=.94a281fb-ce58-4ef2-8fdf-677399220e6b@github.com>
Message-ID: <f7CaLQo9yJuLe8QELGDVLEyIDd0Pln8LWkX68pYtGJg=.5bf78975-8a28-4bd2-a505-8498f0dcad79@github.com>

On Tue, 17 Jun 2025 20:43:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> I think I have responded to all substantial issues, and in most cases updated the PR according to the feedback.
> Specification questions  that have been raised are resolved and the CSR is approved.
> Unless someone identifies a new problem, I am not expecting to make any changes that would be significant to the CSR or JEP. 
> 
> So I will wait a few days to give people a chance to have a last look but I believe we are getting very close to PTT (Propose To Target) for this JEP - with the target being JDK 26.

@prrace, @mrserb I see the tests aren't new, they're updated.

I viewed only the changes since the last time I'd reviewed the changes and all these tests were displayed as new.

Ignoring all the comments to the tests, this leaves only a comment for `src/java.desktop/share/classes/java/awt/doc-files/Modality.html`:


-       and now with single application per-VM there is no
-       distinction between application- and toolkit-modality
+       and now with single application per VM there is no
+       distinction between application- and toolkit-modality.


The fix can be applied in GitHub interface by accepting [my suggestion](https://github.com/openjdk/jdk/pull/25698#discussion_r2154723332).

(I've removed yesterday's comments for `Modality.html`.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25698#issuecomment-2984405779

From aivanov at openjdk.org  Wed Jun 18 14:36:38 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 14:36:38 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <K9CWTpAsp0wdAmFog0VthzHwVfbHKqqxn17Yj5tTuOU=.0fd9f3f6-3cff-4a38-8026-3125e44b70db@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
 <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>
 <x8TJbtS43E5xHiAzQR8M9yaW7V7Y49ChQOtfpmf1ThI=.0435c5c0-48c6-4267-b754-fd0540dcd286@github.com>
 <K9CWTpAsp0wdAmFog0VthzHwVfbHKqqxn17Yj5tTuOU=.0fd9f3f6-3cff-4a38-8026-3125e44b70db@github.com>
Message-ID: <dh6D_a2SOVDFabkkOsB_4fXhqMnhFhx5QcwUkeEiYQo=.4556999a-de79-43de-a1e1-e7291938b200@github.com>

On Tue, 10 Jun 2025 17:59:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Shall I submit a bug to consider removing this code?
>> 
>> Without the comment and an issue to track it, no one will ever remember to look into it.
>
> yes, go ahead.

Submitted [JDK-8359932](https://bugs.openjdk.org/browse/JDK-8359932): _[macosx] Popups don't activate applet's process - unused code?_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2154771290

From aivanov at openjdk.org  Wed Jun 18 14:36:39 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 18 Jun 2025 14:36:39 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <wmdIsdwsrdXCfsWPPB5sYxy9LEEseiuEJS4XmQwTefQ=.256efd90-cdb9-4a04-8802-1ecb8eb1fc54@github.com>
 <17uw3hXlO9gF42gURCLMTCG8KEqVAMPVNpHfy-TWN9E=.28b85575-c4ee-461c-9861-5a2cb7ab80e6@github.com>
Message-ID: <2YdJt4vSc6EfRJckAlQKn-eoyuv4JeIUJ-w1PNeSyuQ=.be6cefad-b0a9-4299-b35d-363226bd8ce0@github.com>

On Mon, 9 Jun 2025 21:03:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Dialog.java line 174:
>> 
>>> 172:          * from the same toolkit except those from its own child hierarchy.
>>> 173:          */
>>> 174:         TOOLKIT_MODAL
>> 
>> Should we add a note that `APPLICATION_MODAL` and `TOOLKIT_MODAL` mean the same thing in the absence of applets or even remove one of them?
>
> Yes, It didn't escape me that they mean essentially the same thing, even more so than they did before
> Theoretically there can be more than one toolkit, although it is not really possible.
> 
> Addressing the nuances of that is outside the scope of this change, so I made the minimum doc change and removing applet isn't the right time to add advice about which to use. So future work there.
> And very unlikely to remove either of them as I suspect the similarities mean that developers probably are 50:50 in which they used, so we'd just break (more) apps if we did.

A bug to clarify the usage [JDK-8359499](https://bugs.openjdk.org/browse/JDK-8359499): _Clarify spec around `TOOLKIT_MODAL` and `APPLICATION_MODAL`_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2154776375

From aivanov at openjdk.org  Thu Jun 19 19:58:37 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 19 Jun 2025 19:58:37 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <p2wM1W_vbDz4VcmeFg_gF0lQTSXabOjY37C7dH2jupY=.de183af8-0147-46b0-8bd3-ab0aee2532e0@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
 <p2wM1W_vbDz4VcmeFg_gF0lQTSXabOjY37C7dH2jupY=.de183af8-0147-46b0-8bd3-ab0aee2532e0@github.com>
Message-ID: <0AjBQg7E18cGIAiGrreBzL_dAbfL1aq1cVt5feRbTUE=.700badca-71fa-4c73-b4c6-b6b150f679a2@github.com>

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

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8359053
>
> src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 353:
> 
>> 351:       the default type was toolkit-modal,
>> 352:       and now with single application per-VM there is no
>> 353:       distinction between application- and toolkit-modality
> 
> Suggestion:
> 
>       and now with single application per VM there is no
>       distinction between application- and toolkit-modality.
> 
> There should be a space between a preposition and a noun and a full stop in the end of the sentence.

@prrace Are you going to accept this suggestion?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2157589041

From aivanov at openjdk.org  Mon Jun 23 13:22:37 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 13:22:37 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v9]
In-Reply-To: <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <Kp19ih36aVfcAYuRxWdnvhFxBXuyTlPzDOXIAfQPJ44=.b7464bd9-7506-49ca-af4c-ffc4e8a26b25@github.com>
Message-ID: <50w959NA7UBm9xNh7VbGGYqXAwWRi2FcC_8PzqfDXEM=.c40ae585-7030-41d5-bb56-6e0118a8aa63@github.com>

On Tue, 17 Jun 2025 18:23:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

There's a tiny suggestion left; it could be amended after this PR is integrated if not taken up here.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2950107360

From prr at openjdk.org  Mon Jun 23 18:58:32 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Jun 2025 18:58:32 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v10]
In-Reply-To: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
Message-ID: <JmmOSkORy-UpU_xBaa1v2dkB1rRHL54C-Ymu0-c2I1o=.85a0e584-629c-404e-b260-148760ea7c66@github.com>

> This is the implementation of JEP 504 - Remove the Applet API.
> API changes are
> - Remove the entire java.applet package
> - Remove the javax/swing/JApplet class
> - Remove applet related APIs in java.beans
> - Update javadoc referring to applets, including one gif image - now changed to an svg image
> - 
> Other changes are
> - Remove references to the removed classes
> - Remove obsolete tests
> - Update obsolete code comments
> 
> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
> release as this JEP is integrated.
> 
> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8359053

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25698/files
  - new: https://git.openjdk.org/jdk/pull/25698/files/253d2bc0..1d75d248

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25698&range=08-09

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

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

From prr at openjdk.org  Mon Jun 23 18:58:34 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Jun 2025 18:58:34 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v10]
In-Reply-To: <NRMHh_Rj41X5PjfTPzIXl-7IqiwaOx9klvXQUxR_9Ss=.577f1f92-a8e3-4654-aba6-775b6770c235@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <WFu6qdUdQg3FqOCCHdZ-tVmWlXjcD9tTCyBseRHLx1k=.552c4bf7-b203-4e70-b9e8-ca8bfc0c73aa@github.com>
 <EuuaFGly5DQOH5YzdrDkO2akvU36upPDQYYfy_S632w=.60fadcc5-74d4-41a9-add6-b5220c94d619@github.com>
 <NRMHh_Rj41X5PjfTPzIXl-7IqiwaOx9klvXQUxR_9Ss=.577f1f92-a8e3-4654-aba6-775b6770c235@github.com>
Message-ID: <-rJLS1VZJfK5uk9gkurAPsiYDEqrO4E7lfn7g594wm4=.edd40711-b1d3-46fb-8b80-3dba2aba0bf7@github.com>

On Mon, 9 Jun 2025 21:39:26 GMT, Phil Race <prr at openjdk.org> wrote:

>> PR for this issue has been created here: https://github.com/openjdk/jdk/pull/25703.
>
> noted.

8358729 is now pushed. So reverting Problem listing as expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2162337149

From aivanov at openjdk.org  Mon Jun 23 19:44:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Jun 2025 19:44:45 GMT
Subject: <i18n dev> RFR: 8359053: Implement JEP 504 - Remove the Applet
 API [v10]
In-Reply-To: <JmmOSkORy-UpU_xBaa1v2dkB1rRHL54C-Ymu0-c2I1o=.85a0e584-629c-404e-b260-148760ea7c66@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <JmmOSkORy-UpU_xBaa1v2dkB1rRHL54C-Ymu0-c2I1o=.85a0e584-629c-404e-b260-148760ea7c66@github.com>
Message-ID: <5hv53zmZA9kKblG14CHqjUjg1tXK_y6RePXkaRKbXAI=.0dc6287e-1af8-402f-862f-cc2da1075909@github.com>

On Mon, 23 Jun 2025 18:58:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 504 - Remove the Applet API.
>> API changes are
>> - Remove the entire java.applet package
>> - Remove the javax/swing/JApplet class
>> - Remove applet related APIs in java.beans
>> - Update javadoc referring to applets, including one gif image - now changed to an svg image
>> - 
>> Other changes are
>> - Remove references to the removed classes
>> - Remove obsolete tests
>> - Update obsolete code comments
>> 
>> sun.awt.AppContext is even more obsolete now than it was before, but eliminating uses of that will be is not required,
>> and will be follow-on internal clean up, at a later date, under unrelated bug ids, and likely not completed in the same
>> release as this JEP is integrated.
>> 
>> I have extensively tested this - running all the automated tests used by CI tiers 1 to 8.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8359053

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/doc-files/Modality.html line 352:

> 350:       <code>Dialog(owner, true)</code>, etc. Prior to JDK 6
> 351:       the default type was toolkit-modal,
> 352:       and now with single application per-VM there is no

Why is it ?per-VM? instead of ?per VM??

??Single application per VM??, in this sentence ?per? is a preposition and ?VM? is a noun, don't you agree? There should be a space, not a hyphen.

If it were ?per-VM application?, then it would be spelt with a hyphen.

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

PR Review: https://git.openjdk.org/jdk/pull/25698#pullrequestreview-2951339948
PR Review Comment: https://git.openjdk.org/jdk/pull/25698#discussion_r2162407407

From duke at openjdk.org  Tue Jun 24 04:24:28 2025
From: duke at openjdk.org (duke)
Date: Tue, 24 Jun 2025 04:24:28 GMT
Subject: <i18n dev> RFR: 8294226: Document missing
 UnsupportedTemporalTypeException
In-Reply-To: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
References: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
Message-ID: <ha0AXyaJtIFHmnFY79smX-Cmal6c00fehxCGUUwVSoU=.e6cbf671-f5bb-4925-b867-4dd22835efaf@github.com>

On Mon, 16 Jun 2025 16:36:43 GMT, Gautham Krishnan <gkrishnan at openjdk.org> wrote:

> Some methods in the java.time.chrono interfaces?ChronoLocalDate, ChronoLocalDateTime, and ChronoZonedDateTime?override methods from the java.time.temporal.Temporal interface that are documented to throw UnsupportedTemporalTypeException when given unsupported fields or units.
> 
> These overridden methods include:
> 
> with(TemporalField, long)
> 
> plus(long, TemporalUnit)
> 
> minus(long, TemporalUnit)
> 
> However, their Javadoc in the chrono interfaces does not mention the possibility of this exception, resulting in incomplete or inconsistent documentation. This contrasts with the parent Temporal interface, which explicitly documents the exception.

@gauthamkrishnanibm 
Your change (at version 15558c58513ff2168ae57a67d36ea12492534ffd) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25836#issuecomment-2998753203

From gkrishnan at openjdk.org  Tue Jun 24 14:56:35 2025
From: gkrishnan at openjdk.org (Gautham Krishnan)
Date: Tue, 24 Jun 2025 14:56:35 GMT
Subject: <i18n dev> Integrated: 8294226: Document missing
 UnsupportedTemporalTypeException
In-Reply-To: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
References: <vQnDqeqwMBOd-ezhmNDl0eb09e90WRUCYrt9jz_Wii0=.78c4fe19-6ada-4475-a69e-2ff8a487e125@github.com>
Message-ID: <XDvf5NkpD1g2vGwsa_OOa6khrSJ6Rl14pc-Z72ZKs1s=.1b3fd638-e1a0-4156-a170-5f1d4559560e@github.com>

On Mon, 16 Jun 2025 16:36:43 GMT, Gautham Krishnan <gkrishnan at openjdk.org> wrote:

> Some methods in the java.time.chrono interfaces?ChronoLocalDate, ChronoLocalDateTime, and ChronoZonedDateTime?override methods from the java.time.temporal.Temporal interface that are documented to throw UnsupportedTemporalTypeException when given unsupported fields or units.
> 
> These overridden methods include:
> 
> with(TemporalField, long)
> 
> plus(long, TemporalUnit)
> 
> minus(long, TemporalUnit)
> 
> However, their Javadoc in the chrono interfaces does not mention the possibility of this exception, resulting in incomplete or inconsistent documentation. This contrasts with the parent Temporal interface, which explicitly documents the exception.

This pull request has now been integrated.

Changeset: 54acadbe
Author:    Gautham Krishnan <gkrishnan at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54acadbe668f6feced6eb9c28bcf46d1b3986eec
Stats:     10 lines in 3 files changed: 8 ins; 0 del; 2 mod

8294226: Document missing UnsupportedTemporalTypeException

Reviewed-by: rriggs, naoto

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

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

From jpai at openjdk.org  Fri Jun 27 13:45:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 27 Jun 2025 13:45:47 GMT
Subject: <i18n dev> RFR: 8342868: Errors related to unused code on
 Windows after 8339120 in core libs [v2]
In-Reply-To: <3LBsjxpWNEAajok5P7-DTOKRKkUmGmyjudWTWlshZ64=.3780c643-dd12-489f-a237-cc3b32b642e0@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
 <3LBsjxpWNEAajok5P7-DTOKRKkUmGmyjudWTWlshZ64=.3780c643-dd12-489f-a237-cc3b32b642e0@github.com>
Message-ID: <uR8156yK3B-4z7Y1d-Iso0zq9Whzt3txQyBMwNk0_D4=.b6045511-7f14-49d5-aa65-154bd067c5ca@github.com>

On Wed, 23 Apr 2025 06:16:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the got local
>
> Stay open

Hello @TheShermanTanker, I see that this PR is marked as ready for integration since several months. But there's also your comment which says:

> I still need awt and accessibility to be approved 

I don't see any client area changes in this PR. Is there anything that's needed to be done to move forward with integrating this? I don't mean that you should integrate it "now" - I see that this branch hasn't been merged against master branch for several months, so that would be the first thing to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-3013136883

From naoto at openjdk.org  Fri Jun 27 20:50:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Jun 2025 20:50:26 GMT
Subject: <i18n dev> RFR: 8360774: Use text representation of normalization
 data files
Message-ID: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>

The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process

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

Commit messages:
 - initial commit

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

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

From ihse at openjdk.org  Fri Jun 27 21:22:21 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 27 Jun 2025 21:22:21 GMT
Subject: <i18n dev> RFR: 8360774: Use text representation of
 normalization data files
In-Reply-To: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
References: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
Message-ID: <mdJcOOPTO-L7nwZJf1okKoK5yb7EaUKYb6MvFZzJKOc=.6299d390-2fed-4f80-ba07-a5c9902bf79c@github.com>

On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process

What is the point of this change? If the files were changed to some kind of readable text format, I would think it was a good change. Also, if this is the representation that we get from upstream, then I can understand it as well (but then a comment about it would be good).

Just converting a binary file to base64 does not accomplish anything of value. It is true that we try to avoid binary files, but if what we need actually *is* a binary file, then we better store it as such, rather than to taking a detour over base64.

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

PR Comment: https://git.openjdk.org/jdk/pull/26027#issuecomment-3014373091

From naoto at openjdk.org  Fri Jun 27 21:34:37 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Jun 2025 21:34:37 GMT
Subject: <i18n dev> RFR: 8360774: Use text representation of
 normalization data files
In-Reply-To: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
References: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
Message-ID: <Pkb3FmjbOGTVdtTWqssZ8xljAnU3d2beR4l3XrQCBy8=.3dba0e2e-7b81-43b4-8326-3cd0e5d0f962@github.com>

On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process

> Just converting a binary file to base64 does not accomplish anything of value. It is true that we try to avoid binary files, but if what we need actually _is_ a binary file, then we better store it as such, rather than to taking a detour over base64.

It is merely to avoid checking binary files in the repository. If we are OK continuing to do so, I am fine with it

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

PR Comment: https://git.openjdk.org/jdk/pull/26027#issuecomment-3014393670

From ihse at openjdk.org  Sun Jun 29 21:39:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Sun, 29 Jun 2025 21:39:37 GMT
Subject: <i18n dev> RFR: 8360774: Use text representation of
 normalization data files
In-Reply-To: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
References: <TOEIN-RxBEAKv4Vleaa0WtyMijKUwSGuF_31bQA-pCo=.88f82538-a7ec-4dc7-b6fe-744906fbc48b@github.com>
Message-ID: <JzESZdqeWiQSf9IHdzA2p665NLIf86zyer7EWoO6Fis=.0e3673f5-c834-4a9e-975b-f626343de9fb@github.com>

On Fri, 27 Jun 2025 20:45:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The ICU4J component currently stores binary data files directly in the repository. This change replaces them with base64-encoded text files and converts them to binary during the build process

I don't see any benefit of checking in base64-encoded files that are inherently binary. If anyone else have a different opinion, let's hear it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26027#issuecomment-3017150314