From abhiscxk at openjdk.org  Tue Jul  1 04:43:48 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 1 Jul 2025 04:43:48 GMT
Subject: RFR: 8355478: DoubleActionESC.java fails intermittently [v9]
In-Reply-To: <cWZ_37dtwSYyUeKmmCeKkemoxFDaJqcp_oHqtrE2GJM=.ab3fefa8-f942-4b67-9c52-439b391aa0ba@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
 <cWZ_37dtwSYyUeKmmCeKkemoxFDaJqcp_oHqtrE2GJM=.ab3fefa8-f942-4b67-9c52-439b391aa0ba@github.com>
Message-ID: <owyajmBXn3NYQa_TOzybqRTWHiY91vDO8XBKWkGI-VE=.1b606641-a4f0-467e-8c3f-dd7df7600522@github.com>

On Mon, 30 Jun 2025 18:57:26 GMT, Anass Baya <abaya at openjdk.org> wrote:

>> **Analysis :**
>> 
>> Whether the test passes on the main line or fails, the behavior is still incorrect.
>> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
>> 
>> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
>> 
>> This causes the test to proceed immediately to the validation step:
>> 
>> if (fd.isVisible()) {
>>     throw new RuntimeException("File Dialog is not closed");
>> }
>> 
>> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
>> 
>> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
>> 
>> **Proposed fix:**
>> 
>> set the CountDownLatch to 2
>> 
>> **Proposed enhancements :**
>> 
>> Remove unnecessary threads (Thread and Thread-2)
>> Properly handle delays and robot.waitForIdle()
>> Avoid indefinite blocking on latch.await()
>> 
>> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
>> 
>> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details
>
> Anass Baya has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Run the test with disableGtkFileDialogs
>  - No need for new test

Marked as reviewed by abhiscxk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25184#pullrequestreview-2973451811

From abaya at openjdk.org  Tue Jul  1 04:43:49 2025
From: abaya at openjdk.org (Anass Baya)
Date: Tue, 1 Jul 2025 04:43:49 GMT
Subject: Integrated: 8355478: DoubleActionESC.java fails intermittently
In-Reply-To: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
References: <5JxVLty1Tt73J8ZkcUIwJUd05YhDMXSwDyKJpXEn4eo=.a56fed94-aec9-491f-a045-97728bb37a06@github.com>
Message-ID: <Vk3PZH-idkYJ16CWi4NVENmuzGEBxB9L-0wntSIwf2k=.d09778ab-1edd-4dc5-b581-7b1eb6afaf3c@github.com>

On Mon, 12 May 2025 13:40:06 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Analysis :**
> 
> Whether the test passes on the main line or fails, the behavior is still incorrect.
> This test is meant to ensure that pressing ESC a second time while the file dialog is open behaves correctly.
> 
> However, the CountDownLatch is currently set to 1, which means the test only waits for the first open/close interaction to complete. As a result, it does not wait for the second attempt (opening the dialog again and pressing ESC to close it), because the latch reaches zero after the first attempt.
> 
> This causes the test to proceed immediately to the validation step:
> 
> if (fd.isVisible()) {
>     throw new RuntimeException("File Dialog is not closed");
> }
> 
> At this point, whether the test passes or fails becomes unreliable and undefined, as it depends on the state of the second attempt (whether the file dialog is in the process of opening, being closed, or hasn't even started yet)
> 
> To ensure the test behaves correctly, the CountDownLatch should be set to 2, so it waits for the two attempt of open-close interactions to be completed before moving on to validation.
> 
> **Proposed fix:**
> 
> set the CountDownLatch to 2
> 
> **Proposed enhancements :**
> 
> Remove unnecessary threads (Thread and Thread-2)
> Properly handle delays and robot.waitForIdle()
> Avoid indefinite blocking on latch.await()
> 
> With these enhancements, the test execution time is reduced from around 3 minutes to approximately 1 minute 30 seconds
> 
> The adapted test uncovered a new bug in GTKFileDialog on Linux, which is being tracked under [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981). As a result, it has been added to the ProblemList. See [JDK-8356981](https://bugs.openjdk.org/browse/JDK-8356981) for more details

This pull request has now been integrated.

Changeset: d1052c70
Author:    Anass Baya <abaya at openjdk.org>
Committer: Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d1052c70cbddb025e7f5b71bd61176e63277bba0
Stats:     35 lines in 2 files changed: 13 ins; 8 del; 14 mod

8355478: DoubleActionESC.java fails intermittently

Reviewed-by: aivanov, abhiscxk

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

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

From mvs at openjdk.org  Tue Jul  1 05:02:34 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Tue, 1 Jul 2025 05:02:34 GMT
Subject: RFR: 8361115: javax/swing/JComboBox/bug4276920.java unnecessarily
 throws Error instead of RuntimeException
Message-ID: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>

Issue:
javax/swing/JComboBox/bug4276920.java unnecessarily throws Error instead of RuntimeException whenever a test failure occurs.
This causes unnecessary extra attention in CI systems and triggers task failures as throwing an Error will write the error message to System.err and the CI system will detect it as an 'Error' and fails the task eventually.
But this is just a normal test failure only and just need to throw 'RuntimeException' and no need to throw an 'Error'.

Fix:
Replace 'Error' with 'RuntimeException'

Testing:
Tested using mach5 in all the available platforms.
Tested manually the negative (failure) condition also and verified that its throwing 'RuntimeException' in cases of failure.

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

Commit messages:
 - 8361115: javax/swing/JComboBox/bug4276920.java unnecessarily throws Error instead of RuntimeException

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

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

From rgupta at openjdk.org  Tue Jul  1 10:12:29 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Tue, 1 Jul 2025 10:12:29 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v2]
In-Reply-To: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
Message-ID: <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>

> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
> 
> 
>  finally {
>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>         }
>     public static void disposeFrame() {
>         if (frame != null) {
>             frame.dispose();
>             frame = null;
>         }
>     }

Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:

  8361067: EventQueue.invokeAndWait used

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26043/files
  - new: https://git.openjdk.org/jdk/pull/26043/files/db5a1913..1a2cb6e0

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

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

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

From rgupta at openjdk.org  Tue Jul  1 15:41:48 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Tue, 1 Jul 2025 15:41:48 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v2]
In-Reply-To: <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
Message-ID: <G09XOphkexp_Wh0GwCGiKaTc2KRH6kE6URabtlXFvJk=.69e1c4a9-b0c1-49e0-ba25-a4803781a687@github.com>

On Tue, 1 Jul 2025 10:12:29 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: EventQueue.invokeAndWait used

any volunteer for review?

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

PR Comment: https://git.openjdk.org/jdk/pull/26043#issuecomment-3024558075

From dnguyen at openjdk.org  Tue Jul  1 17:17:40 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 1 Jul 2025 17:17:40 GMT
Subject: RFR: 8360462: [macosx] row selection not working with
 Ctrl+Shift+Down/Up in AquaL&F [v4]
In-Reply-To: <iIGUnCSFJnbrLyckQXUWfxSY6AX-c7O49_thK9ZW5Vg=.ee00defd-d13a-4779-a53f-ecdf05228b73@github.com>
References: <RFE_bdAWoTn7mVOVkgvbkFq2YrJxfiU4shAjoYMV4ew=.2f8bcab5-94a1-4207-81a2-a90da7edaa6f@github.com>
 <iIGUnCSFJnbrLyckQXUWfxSY6AX-c7O49_thK9ZW5Vg=.ee00defd-d13a-4779-a53f-ecdf05228b73@github.com>
Message-ID: <lkZHhewl-CI5AOANPDSUnp-v8lohnj1zAWpoC5n2jDI=.1e8dad6d-ad9b-44bf-a041-a367cfd0e085@github.com>

On Thu, 26 Jun 2025 05:16:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Ctrl+Shift+Down/Up doesn't extend row selection down or up in Aqua L&F as it does in native tree view in Finder.
>> Fixed the keybindings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test modification

LGTM after the whitespace fix.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25966#pullrequestreview-2976342888

From ecaspole at openjdk.org  Tue Jul  1 17:43:51 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 1 Jul 2025 17:43:51 GMT
Subject: RFR: 8361213: J2DAnalyzer should emit the score as a decimal
Message-ID: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>

As mentioned in the bug, I think it would be better to always emit the score as decimal instead of sometimes decimal, sometimes scientific notation.

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

Commit messages:
 - 8361213: J2DAnalyzer should emit the score as a decimal

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

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

From ecaspole at openjdk.org  Tue Jul  1 19:36:13 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 1 Jul 2025 19:36:13 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
Message-ID: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>

Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

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

Commit messages:
 - 8361216: Do not fork javac in J2DBench ant build

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

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

From duke at openjdk.org  Tue Jul  1 20:55:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 1 Jul 2025 20:55:38 GMT
Subject: RFR: 8361213: J2DAnalyzer should emit the score as a decimal
In-Reply-To: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
References: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
Message-ID: <7ippmhHUzMvyhBnWgvC9i02PldcgvMESYeTOH8sSo5k=.149a3ee3-d2b8-431c-b226-830cf6798970@github.com>

On Tue, 1 Jul 2025 17:38:35 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> As mentioned in the bug, I think it would be better to always emit the score as decimal instead of sometimes decimal, sometimes scientific notation.

src/demo/share/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java line 273:

> 271:                 double overallscore = totalscore[i]/numtests[i];
> 272:                 System.out.println("    Number of tests:  "+numtests[i]);
> 273:                 System.out.printf("    Overall average:  %10.4f%n", overallscore);

double overallscore = 2.4322;
        System.out.println("    Overall average:  "+overallscore); // before
        System.out.printf("    Overall average:  %20.4f%n", overallscore); // after


leads to

    Overall average:  2.4322 // before
    Overall average:                2.4322 // after


should it be a fixed 10 width here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26076#discussion_r2178493112

From serb at openjdk.org  Wed Jul  2 02:10:44 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 2 Jul 2025 02:10:44 GMT
Subject: RFR: 8349188: LineBorder does not scale correctly [v3]
In-Reply-To: <zevZKrmusYXbhGfgVE05g-Dfui1DnrRKupj4ikk0w1k=.9c32e7a1-31f4-4c3c-abb3-22f320cf9573@github.com>
References: <kug7LnY4W5qyMNRubPUJMlN1sTlwHxsad7Cym4x2NHc=.ae85ffe0-bcc3-4dcb-85f3-9d9dbf350985@github.com>
 <zevZKrmusYXbhGfgVE05g-Dfui1DnrRKupj4ikk0w1k=.9c32e7a1-31f4-4c3c-abb3-22f320cf9573@github.com>
Message-ID: <lgyUgoxzPX8JaqOkxjLKLAcmBzPziSs4MDLd_VImspc=.575c49ea-a4be-462f-a699-b98a75db93a8@github.com>

On Fri, 27 Jun 2025 19:46:56 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix blank line

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26025#pullrequestreview-2977386275

From serb at openjdk.org  Wed Jul  2 02:10:45 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 2 Jul 2025 02:10:45 GMT
Subject: RFR: 8349188: LineBorder does not scale correctly [v3]
In-Reply-To: <7BXx2SffjA3gTNkytfYV3meBKrle7kLGk6z1vKdR9kM=.c0a87b7b-019f-46a1-adbd-21586ccd6c69@github.com>
References: <kug7LnY4W5qyMNRubPUJMlN1sTlwHxsad7Cym4x2NHc=.ae85ffe0-bcc3-4dcb-85f3-9d9dbf350985@github.com>
 <zevZKrmusYXbhGfgVE05g-Dfui1DnrRKupj4ikk0w1k=.9c32e7a1-31f4-4c3c-abb3-22f320cf9573@github.com>
 <oOOGLvz1hOXCNRotSKA8f_fjJKKxNJk7wZByCdE4oM0=.2da439ac-5f25-408a-b819-b6a68148e486@github.com>
 <e5u5slUrMfVhpUJBAWEvqiHeq6Tpt-QRNp6VSm5w9xo=.d0a3576d-6208-417c-8922-2a518a4797f3@github.com>
 <IO3GvbCOQe8-Ed4UALh3ikqL97k2k7u3unBetzoJvG4=.d7ffe280-6302-4966-ad4c-238a337f3947@github.com>
 <fBafOfy5-QQW4J76HKi7VGRXQAytZV8T7oUTB4EygzU=.49b7a2d2-48d9-48aa-8063-d9f455114342@github.com>
 <YKhW8mh-mfO9PNNyDJIIQQwubFtVp7RNGu3Yu16HoVg=.18312296-4023-4a29-95b6-64b7e3704989@github.com>
 <_N8_XRi55RP11XX0G7ljILmeiWaLc1nBILVS0OxVMHE=.5ac68198-21bc-4e42-9d32-3725d3ff1a7b@github.com>
 <k1PRlNgxOJ3Cc8yVfvnvsghG3P4-YARX0PFF2LmNNRI=.6ae0e472-6731-45ed-a8fa-a3f8f1a0393d@github.com>
 <vwSeyHki00roWlVHL_PH8Vji88XPPIwGP89j3W99_nQ=.e9cc8ff5-8a45-49bf-86d4-37408a8d4de9@github.com>
 <qiVE6I-mkal2IV-BaMBBZuKzUBDep5Hx83w
 oCYNRKQw=.c6bfd27d-e773-4af4-97c2-d297f990f164@github.com>
 <7BXx2SffjA3gTNkytfYV3meBKrle7kLGk6z1vKdR9kM=.c0a87b7b-019f-46a1-adbd-21586ccd6c69@github.com>
Message-ID: <ODG7mfxOO50FpAI65_EIJoD3Jgodn2zKH4wkkWbmEqY=.6d657e89-2fd9-4d91-8467-f7596cf032b7@github.com>

On Mon, 30 Jun 2025 17:07:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> My point is to investigate the difference between clipScale and clipRound to ensure the correct one is used. There was a complex discussion before about similar issue, which is why we currently have two separate versions of this rounding logic. Simply replacing one with the other might not work and some other tweaks should be done.
>
> My point is `clipRound` works good in this use case, *it resolves the problem*, I see no reason not to accept the fix.
> 
> ---
> 
> I agree with your general concern that we should understand better the purpose of each method. Yet no one seems to remember the outcome of that complex discussion, therefore switching to `clipScale` could be postponed; if it's deemed necessary, we can easily change the method, both in the implementation and in the test.
> 
> I submitted [JDK-8361095](https://bugs.openjdk.org/browse/JDK-8361095) to ensure this current discussion isn't forgotten and we figure out the purpose and guidelines for `clipScale` and `clipRound`.

Ok sounds good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26025#discussion_r2178841430

From psadhukhan at openjdk.org  Wed Jul  2 03:09:49 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 2 Jul 2025 03:09:49 GMT
Subject: Integrated: 8360462: [macosx] row selection not working with
 Ctrl+Shift+Down/Up in AquaL&F
In-Reply-To: <RFE_bdAWoTn7mVOVkgvbkFq2YrJxfiU4shAjoYMV4ew=.2f8bcab5-94a1-4207-81a2-a90da7edaa6f@github.com>
References: <RFE_bdAWoTn7mVOVkgvbkFq2YrJxfiU4shAjoYMV4ew=.2f8bcab5-94a1-4207-81a2-a90da7edaa6f@github.com>
Message-ID: <UyNhessGBEo1QwA2VoxwGnaiQm1lFkrgEPJRBKtrFy4=.d4b4e52d-14eb-4bde-9692-005575879cc3@github.com>

On Wed, 25 Jun 2025 04:43:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Ctrl+Shift+Down/Up doesn't extend row selection down or up in Aqua L&F as it does in native tree view in Finder.
> Fixed the keybindings.

This pull request has now been integrated.

Changeset: 2bff8e0a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bff8e0a1382f8820bc2479af87e45dc6b74cdb5
Stats:     118 lines in 2 files changed: 117 ins; 0 del; 1 mod

8360462: [macosx] row selection not working with Ctrl+Shift+Down/Up in AquaL&F

Reviewed-by: dnguyen, abhiscxk

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

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

From ecaspole at openjdk.org  Wed Jul  2 14:49:40 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 2 Jul 2025 14:49:40 GMT
Subject: RFR: 8361213: J2DAnalyzer should emit the score as a decimal
In-Reply-To: <7ippmhHUzMvyhBnWgvC9i02PldcgvMESYeTOH8sSo5k=.149a3ee3-d2b8-431c-b226-830cf6798970@github.com>
References: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
 <7ippmhHUzMvyhBnWgvC9i02PldcgvMESYeTOH8sSo5k=.149a3ee3-d2b8-431c-b226-830cf6798970@github.com>
Message-ID: <-iPlNCMuqTb7W-yTXx4VqBXXk65s15jqYrfKvIUad30=.5065f4fd-b959-4b7b-b7d4-9a8326a91981@github.com>

On Tue, 1 Jul 2025 20:52:50 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> As mentioned in the bug, I think it would be better to always emit the score as decimal instead of sometimes decimal, sometimes scientific notation.
>
> src/demo/share/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java line 273:
> 
>> 271:                 double overallscore = totalscore[i]/numtests[i];
>> 272:                 System.out.println("    Number of tests:  "+numtests[i]);
>> 273:                 System.out.printf("    Overall average:  %10.4f%n", overallscore);
> 
> double overallscore = 2.4322;
>         System.out.println("    Overall average:  "+overallscore); // before
>         System.out.printf("    Overall average:  %20.4f%n", overallscore); // after
> 
> 
> leads to
> 
>     Overall average:  2.4322 // before
>     Overall average:                2.4322 // after
> 
> 
> should it be a fixed 10 width here?

I am not sure what you mean, but with the 10, the scores line up with the rest of the minor stats when it is monospace font like this example -


Summary:
  vimg_text_noaa: 
    Number of tests:  2
    Overall average:  20002.7449
    Best spread:      1.3% variance
    Worst spread:     3.62% variance
    (Basis for results comparison)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26076#discussion_r2180257723

From abhiscxk at openjdk.org  Wed Jul  2 15:11:24 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 2 Jul 2025 15:11:24 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced Tab
 items of JTabbedPane as RadioButton on macOS
Message-ID: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>

Issue : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 

Analysis : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..

Proposed Fix : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.

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

Commit messages:
 - Tab item announcement fix

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

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

From abhiscxk at openjdk.org  Wed Jul  2 15:37:30 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 2 Jul 2025 15:37:30 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
Message-ID: <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>

> Issue : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
> 
> Analysis : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
> 
> Proposed Fix : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26096/files
  - new: https://git.openjdk.org/jdk/pull/26096/files/1873db3a..0bc63054

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

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

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

From duke at openjdk.org  Wed Jul  2 16:13:39 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 2 Jul 2025 16:13:39 GMT
Subject: RFR: 8361213: J2DAnalyzer should emit the score as a decimal
In-Reply-To: <-iPlNCMuqTb7W-yTXx4VqBXXk65s15jqYrfKvIUad30=.5065f4fd-b959-4b7b-b7d4-9a8326a91981@github.com>
References: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
 <7ippmhHUzMvyhBnWgvC9i02PldcgvMESYeTOH8sSo5k=.149a3ee3-d2b8-431c-b226-830cf6798970@github.com>
 <-iPlNCMuqTb7W-yTXx4VqBXXk65s15jqYrfKvIUad30=.5065f4fd-b959-4b7b-b7d4-9a8326a91981@github.com>
Message-ID: <XY8O-VJB93i0MiVA0hkriE1tH6ZNhgFEMeGhdfbXq4M=.8d541d4f-1d6a-4108-a920-7b625927a8b0@github.com>

On Wed, 2 Jul 2025 14:46:45 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> src/demo/share/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java line 273:
>> 
>>> 271:                 double overallscore = totalscore[i]/numtests[i];
>>> 272:                 System.out.println("    Number of tests:  "+numtests[i]);
>>> 273:                 System.out.printf("    Overall average:  %10.4f%n", overallscore);
>> 
>> double overallscore = 2.4322;
>>         System.out.println("    Overall average:  "+overallscore); // before
>>         System.out.printf("    Overall average:  %10.4f%n", overallscore); // after
>> 
>> 
>> leads to
>> 
>>     Overall average:  2.4322 // before
>>     Overall average:      2.4322 // after
>> 
>> 
>> should it be a fixed 10 width here?
>
> I am not sure what you mean, but with the 10, the scores line up with the rest of the minor stats when it is monospace font like this example -
> 
> 
> Summary:
>   vimg_text_noaa: 
>     Number of tests:  2
>     Overall average:  20002.7449
>     Best spread:      1.3% variance
>     Worst spread:     3.62% variance
>     (Basis for results comparison)

Thanks. I was thinking if the difference between the old and new behavior would result in any rendering differences. The example you showed is a special case where the amount of characters is => 10.

If `overallscore` is say `1.678` then it renders like this:

`System.out.printf("    Overall average:  %10.4f%n", overallscore);`

Summary:
  vimg_text_noaa_1: 
    Number of tests:  2
    Overall average:      1,6780
    Best spread:      2.14% variance
    Worst spread:     2.57% variance
    (Basis for results comparison)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26076#discussion_r2180458288

From ecaspole at openjdk.org  Wed Jul  2 18:56:33 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 2 Jul 2025 18:56:33 GMT
Subject: RFR: 8361213: J2DAnalyzer should emit the score as a decimal [v2]
In-Reply-To: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
References: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
Message-ID: <VfcPiMICDwRoZ_h2UIygFu6VW9qhmwFyN65v7BQ8gI8=.02e0456a-f625-47d1-91e7-55b0f6f3c344@github.com>

> As mentioned in the bug, I think it would be better to always emit the score as decimal instead of sometimes decimal, sometimes scientific notation.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Use - to left-align the result

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26076/files
  - new: https://git.openjdk.org/jdk/pull/26076/files/0f3b067a..02da2791

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

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

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

From ecaspole at openjdk.org  Wed Jul  2 18:56:34 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 2 Jul 2025 18:56:34 GMT
Subject: RFR: 8361213: J2DAnalyzer should emit the score as a decimal [v2]
In-Reply-To: <XY8O-VJB93i0MiVA0hkriE1tH6ZNhgFEMeGhdfbXq4M=.8d541d4f-1d6a-4108-a920-7b625927a8b0@github.com>
References: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
 <7ippmhHUzMvyhBnWgvC9i02PldcgvMESYeTOH8sSo5k=.149a3ee3-d2b8-431c-b226-830cf6798970@github.com>
 <-iPlNCMuqTb7W-yTXx4VqBXXk65s15jqYrfKvIUad30=.5065f4fd-b959-4b7b-b7d4-9a8326a91981@github.com>
 <XY8O-VJB93i0MiVA0hkriE1tH6ZNhgFEMeGhdfbXq4M=.8d541d4f-1d6a-4108-a920-7b625927a8b0@github.com>
Message-ID: <5AizXDmi8Pbbqk173WsZYj68uY6Sd0w6ouphyh9iRYI=.79dda1c8-e2ad-4538-800e-358cf42541ec@github.com>

On Wed, 2 Jul 2025 16:10:10 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> I am not sure what you mean, but with the 10, the scores line up with the rest of the minor stats when it is monospace font like this example -
>> 
>> 
>> Summary:
>>   vimg_text_noaa: 
>>     Number of tests:  2
>>     Overall average:  20002.7449
>>     Best spread:      1.3% variance
>>     Worst spread:     3.62% variance
>>     (Basis for results comparison)
>
> Thanks. I was thinking if the difference between the old and new behavior would result in any rendering differences. The example you showed is a special case where the amount of characters is => 10.
> 
> If `overallscore` is say `1.678` then it renders like this:
> 
> `System.out.printf("    Overall average:  %10.4f%n", overallscore);`
> 
> Summary:
>   vimg_text_noaa_1: 
>     Number of tests:  2
>     Overall average:      1,6780
>     Best spread:      2.14% variance
>     Worst spread:     2.57% variance
>     (Basis for results comparison)

The scores are chars/sec or pixels/sec so it is always a big number with (usually) many decimal places. 

    Overall average:  19046.2340
    Overall average:  20010.8816
    Overall average:  19829.0079
    Overall average:  16595601.1584
    Overall average:  61195068.8361

I added a - to the format string to always left align the result which should work for big or small numbers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26076#discussion_r2180771315

From serb at openjdk.org  Wed Jul  2 19:39:37 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 2 Jul 2025 19:39:37 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <O2pgej848hz-egNnBEZtklwWGy6TmDenFo2gd7RY15I=.0cdca928-a171-49ab-bac2-72b33c2913a0@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

Maybe we should drop the ant script and use only makefile which have a way to override default [source/target](https://github.com/openjdk/jdk/blob/ea86a20e6d74baea54df32415d9096d3b7bba1d7/src/demo/share/java2d/J2DBench/Makefile#L33)?

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3029101405

From aivanov at openjdk.org  Wed Jul  2 19:40:43 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 2 Jul 2025 19:40:43 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v11]
In-Reply-To: <6zA_Ov7yomMGPHkeHf3g8F513Cqr_mzF2EeZTrV3JcU=.2c228efa-548f-493d-94ad-365acd592cd4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <PkiaNPoIbIto3C8x6-8TrPzHtxGgXjxiCL4MKs1spt0=.23f88657-b26b-4df1-bda5-f865ab497cfe@github.com>
 <o5uXQjF3pnxoUgKFC5ij8U2EdasRGeujPnGI-cudG5g=.08a6eb8a-b559-47a3-8a3c-5dce89580f97@github.com>
 <s-uceID9jflJAnxXui2hXNe0j69Xi-fnbb1R8jyjdao=.ed721d4c-2cec-47d7-966e-549d11c6700b@github.com>
 <6zA_Ov7yomMGPHkeHf3g8F513Cqr_mzF2EeZTrV3JcU=.2c228efa-548f-493d-94ad-365acd592cd4@github.com>
Message-ID: <fX5gd0LIsTYPdqt0oZYKvo8oNzW9wIkOlUx4EsoFoZY=.9f923a11-83a2-466b-97c7-8aa41f696c7d@github.com>

On Tue, 24 Jun 2025 14:01:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Note?that this?was a?preview language?feature until?**JDK?25**.
>
> I haven't done my due diligence to verify whether this feature can be used. Even if this particular way can't be used, it's still a viable option, just move the code above into a helper method.
> 
> 
>     public ImageIcon(Image image, String description) {
>         this.image = image;
>         this.description = description;
> 
>         loadImage(image);
>     }
> 
>     public ImageIcon (Image image) {
>         this(image, getImageComment(image));
>     }
> 
>     /**
>      * {@return the {@code "comment"} property of the image
>      * if the value of the property is a sting}
>      * @param image the image to get the {@code "comment"}  property
>      */
>     private static String getImageComment(Image image) {
>         if (image == null) {
>             return null;
>         }
> 
>         Object o = image.getProperty("comment", null);
>         return (o instanceof String) ? (String) o : null;
>     }
> 
> 
> This should be done separately from this changeset, I think, to have shorter, more specific changes.

> Note that this was a preview language feature until **JDK 25**.

Huh? We're developing JDK 26 now, so the **Flexible Constructor Bodies** [[JEP 513](https://openjdk.org/jeps/513)] feature can safely be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2180838579

From ecaspole at openjdk.org  Wed Jul  2 20:11:39 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 2 Jul 2025 20:11:39 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <DVl4QR-czuOEzTkOWes5Q69560qnHF6AGOcBcaFWExQ=.2c60bb67-f252-495f-a4fa-23fc1d6bfada@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

We only test back to 8 so we don't need to change it more often. But JDK 24/25 does not support source 7 so we should do something. I think JAVA_HOME with ant is simpler than specifying lots of vars to makefile but I don't have strong opinion.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3029179400

From achung at openjdk.org  Wed Jul  2 21:25:28 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 2 Jul 2025 21:25:28 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v21]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <5BjWu3uFivY3Ab2uxG1aclb5G340ptpVCGQ_DbCdBXM=.d11682ac-00ca-4afe-a4a9-6237ac53e632@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  remove /lib/client/ from tests with ER removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/9aa82019..8347d2fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=19-20

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

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

From psadhukhan at openjdk.org  Thu Jul  3 05:25:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 3 Jul 2025 05:25:59 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v12]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  javadoc change, description setting removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/e76c4ff1..c263419e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=10-11

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

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

From psadhukhan at openjdk.org  Thu Jul  3 05:36:44 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 3 Jul 2025 05:36:44 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v11]
In-Reply-To: <IN0dxVO5ehtVktl5z5H4tSAQc5_UUf0_W3E8filRva0=.fc69e5f1-7047-4060-8cf7-3b39682fb58f@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <PkiaNPoIbIto3C8x6-8TrPzHtxGgXjxiCL4MKs1spt0=.23f88657-b26b-4df1-bda5-f865ab497cfe@github.com>
 <IN0dxVO5ehtVktl5z5H4tSAQc5_UUf0_W3E8filRva0=.fc69e5f1-7047-4060-8cf7-3b39682fb58f@github.com>
Message-ID: <0IRNFwRvYrSBILTYK_fdJlB3SMg4mOf-8arMXDhQwT0=.45deeb79-66a0-479a-9bcf-290da7bdba53@github.com>

On Fri, 20 Jun 2025 11:54:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove resetting description from constructor as it is already null
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 219:
> 
>> 217:      * Creates an ImageIcon from an image object.
>> 218:      * Setting a {@code null} image means
>> 219:      * no image will be rendered.
> 
> Suggestion:
> 
>      * If the image is {@code null}, no icon will be rendered.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2181804281

From psadhukhan at openjdk.org  Thu Jul  3 06:48:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 3 Jul 2025 06:48:45 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v12]
In-Reply-To: <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
Message-ID: <edhTglb25_ja08h79DC0LskDspzmeQXY2xFTajUKuuM=.014d3475-fbd6-4a19-b16c-ce1f43e86553@github.com>

On Thu, 3 Jul 2025 05:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc change, description setting removed

> Both image and description are two independent fields of ImageIcon object, each has its own getter and setter, and each can be changed independently. We should not enforce the order of calls: if an app developer wants to set the image to null, temporarily or not, the value of the description has to be preserved

I guess resetting the description came from the fact that description is mentioned as "Sets the description of the image. This is meant to be a brief textual description of the object." so if image is null, the description of the image logically should be nothing.

But again, as pointed out, description has its own setter and getter so user would expect whatever description is stored either by [ImageIcon](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/ImageIcon.html#%3Cinit%3E(java.awt.Image,java.lang.String))([Image](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Image.html) image, [String](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/String.html) description) constructor or `setDescription `would be returned same via `getDescription`..
If not, the spec for set and getDescription needs to be modified to to incorporate null-image scenario.
But all-in-all I guess this description change can go in separate PR along with [above change](https://github.com/openjdk/jdk/pull/25767#discussion_r2164102520)

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3031070723

From duke at openjdk.org  Thu Jul  3 08:41:41 2025
From: duke at openjdk.org (ExE Boss)
Date: Thu, 3 Jul 2025 08:41:41 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v11]
In-Reply-To: <fX5gd0LIsTYPdqt0oZYKvo8oNzW9wIkOlUx4EsoFoZY=.9f923a11-83a2-466b-97c7-8aa41f696c7d@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <PkiaNPoIbIto3C8x6-8TrPzHtxGgXjxiCL4MKs1spt0=.23f88657-b26b-4df1-bda5-f865ab497cfe@github.com>
 <o5uXQjF3pnxoUgKFC5ij8U2EdasRGeujPnGI-cudG5g=.08a6eb8a-b559-47a3-8a3c-5dce89580f97@github.com>
 <s-uceID9jflJAnxXui2hXNe0j69Xi-fnbb1R8jyjdao=.ed721d4c-2cec-47d7-966e-549d11c6700b@github.com>
 <6zA_Ov7yomMGPHkeHf3g8F513Cqr_mzF2EeZTrV3JcU=.2c228efa-548f-493d-94ad-365acd592cd4@github.com>
 <fX5gd0LIsTYPdqt0oZYKvo8oNzW9wIkOlUx4EsoFoZY=.9f923a11-83a2-466b-97c7-8aa41f696c7d@github.com>
Message-ID: <9WUpD0-kEWouYC894MdY6_nmvTxBmyQnL1LQf56YpTk=.325bb064-13b7-4315-9db2-d13114a784fa@github.com>

On Wed, 2 Jul 2025 19:38:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I haven't done my due diligence to verify whether this feature can be used. Even if this particular way can't be used, it's still a viable option, just move the code above into a helper method.
>> 
>> 
>>     public ImageIcon(Image image, String description) {
>>         this.image = image;
>>         this.description = description;
>> 
>>         loadImage(image);
>>     }
>> 
>>     public ImageIcon (Image image) {
>>         this(image, getImageComment(image));
>>     }
>> 
>>     /**
>>      * {@return the {@code "comment"} property of the image
>>      * if the value of the property is a sting}
>>      * @param image the image to get the {@code "comment"}  property
>>      */
>>     private static String getImageComment(Image image) {
>>         if (image == null) {
>>             return null;
>>         }
>> 
>>         Object o = image.getProperty("comment", null);
>>         return (o instanceof String) ? (String) o : null;
>>     }
>> 
>> 
>> This should be done separately from this changeset, I think, to have shorter, more specific changes.
>
>> Note that this was a preview language feature until **JDK 25**.
> 
> Huh? We're developing JDK 26 now, so the **Flexible Constructor Bodies** [[JEP 513](https://openjdk.org/jeps/513)] feature can safely be used.

Yes, but?it?complicates backports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2182206993

From aivanov at openjdk.org  Thu Jul  3 09:28:44 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 3 Jul 2025 09:28:44 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v11]
In-Reply-To: <IN0dxVO5ehtVktl5z5H4tSAQc5_UUf0_W3E8filRva0=.fc69e5f1-7047-4060-8cf7-3b39682fb58f@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <PkiaNPoIbIto3C8x6-8TrPzHtxGgXjxiCL4MKs1spt0=.23f88657-b26b-4df1-bda5-f865ab497cfe@github.com>
 <IN0dxVO5ehtVktl5z5H4tSAQc5_UUf0_W3E8filRva0=.fc69e5f1-7047-4060-8cf7-3b39682fb58f@github.com>
Message-ID: <gPsWDMabAdCAJoYSS--VYCcQdpiAb4G72UJXxROM90I=.3a3d657f-fc54-4e7b-9740-b0f1dd41dec8@github.com>

On Fri, 20 Jun 2025 11:55:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove resetting description from constructor as it is already null
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 230:
> 
>> 228:         if (image == null) {
>> 229:             return;
>> 230:         }
> 
> So, are we changing the constructors that accept `Image`?

Are we changing the constructor to accept `null` as the `Image` parameter?

There's [a long thread](https://github.com/openjdk/jdk/pull/25767/files#r2155610976) about *consistent* behaviour of the `ImageIcon` constructors, yet no decision has been taken.

@prrace mentioned consistency among constructors, and `ImageIcon` constructors consistently throw `NullPointerException` for `null` image. In fact, he referred to setting the `description` field, but this is moot if a constructor throws.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2182302073

From aivanov at openjdk.org  Thu Jul  3 09:38:47 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 3 Jul 2025 09:38:47 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v11]
In-Reply-To: <9WUpD0-kEWouYC894MdY6_nmvTxBmyQnL1LQf56YpTk=.325bb064-13b7-4315-9db2-d13114a784fa@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <PkiaNPoIbIto3C8x6-8TrPzHtxGgXjxiCL4MKs1spt0=.23f88657-b26b-4df1-bda5-f865ab497cfe@github.com>
 <o5uXQjF3pnxoUgKFC5ij8U2EdasRGeujPnGI-cudG5g=.08a6eb8a-b559-47a3-8a3c-5dce89580f97@github.com>
 <s-uceID9jflJAnxXui2hXNe0j69Xi-fnbb1R8jyjdao=.ed721d4c-2cec-47d7-966e-549d11c6700b@github.com>
 <6zA_Ov7yomMGPHkeHf3g8F513Cqr_mzF2EeZTrV3JcU=.2c228efa-548f-493d-94ad-365acd592cd4@github.com>
 <fX5gd0LIsTYPdqt0oZYKvo8oNzW9wIkOlUx4EsoFoZY=.9f923a11-83a2-466b-97c7-8aa41f696c7d@github.com>
 <9WUpD0-kEWouYC894MdY6_nmvTxBmyQnL1LQf56YpTk=.325bb064-13b7-4315-9db2-d13114a784fa@github.com>
Message-ID: <257zFeDGaIM5O5Xyj13yfGA6PQezBvfnpGcdKnUnRhg=.cd4fa8bf-2492-4073-bcdf-0266e84bc1e4@github.com>

On Thu, 3 Jul 2025 08:38:51 GMT, ExE Boss <duke at openjdk.org> wrote:

> Yes, but it complicates backports.

Yes, it complicates backports, but this implies backports are possible. If the specification is updated, the backports will likely be impossible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2182328138

From aivanov at openjdk.org  Thu Jul  3 09:46:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 3 Jul 2025 09:46:45 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v12]
In-Reply-To: <edhTglb25_ja08h79DC0LskDspzmeQXY2xFTajUKuuM=.014d3475-fbd6-4a19-b16c-ce1f43e86553@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
 <edhTglb25_ja08h79DC0LskDspzmeQXY2xFTajUKuuM=.014d3475-fbd6-4a19-b16c-ce1f43e86553@github.com>
Message-ID: <kX8OW33TLxOOfd8-jBp4RpsqbLG5H7sno2jRWAf7Lr4=.bb6932f8-5f32-44ec-ba03-081c8f6916e7@github.com>

On Thu, 3 Jul 2025 06:46:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Both image and description are two independent fields of ImageIcon object, each has its own getter and setter, and each can be changed independently. We should not enforce the order of calls: if an app developer wants to set the image to null, temporarily or not, the value of the description has to be preserved
> 
> I guess resetting the description came from the fact that description is mentioned as "Sets the description of the image. This is meant to be a brief textual description of the object." so if image is null, the description of the image logically should be nothing.

I agree that a description for a `null` image doesn't make sense.

Then, it also depends on how it's really handled. If the image in the `ImageIcon` object is `null`, the description could be ignored.

> But again, as pointed out, description has its own setter and getter so user would expect whatever description is stored either by [ImageIcon](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/ImageIcon.html#%3Cinit%3E(java.awt.Image,java.lang.String))([Image](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/java/awt/Image.html) image, [String](https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/String.html) description) constructor or `setDescription `would be returned same via `getDescription`.. If not, the spec for set and getDescription needs to be modified to to incorporate null-image scenario.

Exactly.

Updating the specification for `setDescription` and `getDescription` to indicate the description will be set to `null` if the image is set to `null` will make the API cumbersome and less clear.

I prefer leaving the description intact.

> But all-in-all I guess this description change can go in separate PR along with [above change](https://github.com/openjdk/jdk/pull/25767#discussion_r2164102520)

Have anyone submit a bug to address this deficiency? If not, I'll submit one.

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3031604978

From ihse at openjdk.org  Thu Jul  3 10:17:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Jul 2025 10:17:38 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <it-mPZb7Su9a8pIfoA9XJUZ8RkhQORkUa244gY4Ayi8=.2bd1a0f1-ffc9-4b5a-b596-bc9f26dda9ca@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

Where, how and why are this antscript or the `src/demo/share/java2d/J2DBench/Makefile` used? 

The JDK build system builds the demos using `make/CompileDemos.gmk`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3031704741

From aivanov at openjdk.org  Thu Jul  3 14:27:48 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 3 Jul 2025 14:27:48 GMT
Subject: RFR: 8349188: LineBorder does not scale correctly [v3]
In-Reply-To: <zevZKrmusYXbhGfgVE05g-Dfui1DnrRKupj4ikk0w1k=.9c32e7a1-31f4-4c3c-abb3-22f320cf9573@github.com>
References: <kug7LnY4W5qyMNRubPUJMlN1sTlwHxsad7Cym4x2NHc=.ae85ffe0-bcc3-4dcb-85f3-9d9dbf350985@github.com>
 <zevZKrmusYXbhGfgVE05g-Dfui1DnrRKupj4ikk0w1k=.9c32e7a1-31f4-4c3c-abb3-22f320cf9573@github.com>
Message-ID: <Un3rXtD5NinMmDqlOfn_W_e4pPIbF_MogczyCgD-gl4=.fbfcfce4-ae2a-4dd3-9802-80c26fab6952@github.com>

On Fri, 27 Jun 2025 19:46:56 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change.
>> 
>> Testing done.
>
> Rajat Mahajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix blank line

Nudge the Skara bots with a comment?

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

PR Comment: https://git.openjdk.org/jdk/pull/26025#issuecomment-3032468012

From rmahajan at openjdk.org  Thu Jul  3 14:27:49 2025
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 3 Jul 2025 14:27:49 GMT
Subject: Integrated: 8349188: LineBorder does not scale correctly
In-Reply-To: <kug7LnY4W5qyMNRubPUJMlN1sTlwHxsad7Cym4x2NHc=.ae85ffe0-bcc3-4dcb-85f3-9d9dbf350985@github.com>
References: <kug7LnY4W5qyMNRubPUJMlN1sTlwHxsad7Cym4x2NHc=.ae85ffe0-bcc3-4dcb-85f3-9d9dbf350985@github.com>
Message-ID: <eK6CeH9ZNvvNeFYYMdD3-xG1IxmE1jkBqK32UB72GCI=.95639c4c-216c-4cdb-adf6-eccb236eee03@github.com>

On Fri, 27 Jun 2025 18:11:46 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Modified the code to account for border thickness correctly and updated the related tests to make sure we are testing the new change.
> 
> Testing done.

This pull request has now been integrated.

Changeset: 24117c6e
Author:    Rajat Mahajan <rmahajan at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/24117c6e9aa862bad839e93eff70810a75605ac5
Stats:     95 lines in 3 files changed: 42 ins; 19 del; 34 mod

8349188: LineBorder does not scale correctly

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

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

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

From ecaspole at openjdk.org  Thu Jul  3 15:16:42 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 3 Jul 2025 15:16:42 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <knqCTP1xHBkcpCJeQKYSSKo1gKdyUuRqL6Wq8PrKIvc=.c5df48c8-68c3-4cbc-8330-f964b1c6d21b@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

I dont know the history of J2DBench or how its build was developed. It looks like J2DBench is not included in the JDK demos build. My goal here, if possible, is to make a build of it from the mainline repo that is JDK8 compatible, so we can use one jar for all perf testing from 8 onwards. Hopefully someone with some client history can comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3032640471

From achung at openjdk.org  Thu Jul  3 15:55:23 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 3 Jul 2025 15:55:23 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v22]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <Hzte_IUFOGKwJ7th5xZPB-o8J8AqopfRzRFd3OYb0j4=.7875621f-2879-4c9b-be2a-65f3c49b91a5@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  remove ER from remaining modal test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/8347d2fb..9f198856

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=20-21

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

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

From ihse at openjdk.org  Thu Jul  3 16:04:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 3 Jul 2025 16:04:46 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <y8jPEiaX1PLuQlSFvYTDYljPiuUqA-Jl2Chm0UjxS1M=.9fe83b21-9612-4dc6-8612-deb1d88fb0c0@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

The long-term goal is to remove demos from mainline. Most have already been removed. The few that remains was used for client testing, iirc. They have not been updated since jdk8 and are unlikely to be. Can't you just build the jar from JDK8? Or if you need the code for testing, create a copy alongside your other tests?

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3032805653

From ecaspole at openjdk.org  Thu Jul  3 16:36:40 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 3 Jul 2025 16:36:40 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <UFf93hHmBGr_-fUbYov8PQ9JOEX9fdmC9IlFYmU0nKQ=.eb37ca35-be1d-4427-97a3-190713295488@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

Could we move J2DBench under test next to micro/ ? It's not a demo, it's a benchmark but somehow it ended up under demos. It should remain available to contributors.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3032886850

From prr at openjdk.org  Thu Jul  3 18:53:40 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 18:53:40 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <J0KHRnxZq7gMfyMKVKQTGOyH_Ty7mgigm7mreHxRIkQ=.0d6fb3fd-9ca3-4891-b94b-db0acb8cea12@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

It isn't a demo and it isn't a jtreg test. 
Everything under src/share/demo is client related which may be why it is there.
But the right home for it is
test/jdk/performance/client
next to RenderPerfTest and SwingMark
But that location came along a long time after j2dbench

I kind of wonder if
test/jdk/performance/client
should be
test/jdk/client/performance/
and then we could have
test/jdk/client/jfc
for SwingSet etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3033231886
PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3033255013

From prr at openjdk.org  Thu Jul  3 18:53:41 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 18:53:41 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <y8jPEiaX1PLuQlSFvYTDYljPiuUqA-Jl2Chm0UjxS1M=.9fe83b21-9612-4dc6-8612-deb1d88fb0c0@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
 <y8jPEiaX1PLuQlSFvYTDYljPiuUqA-Jl2Chm0UjxS1M=.9fe83b21-9612-4dc6-8612-deb1d88fb0c0@github.com>
Message-ID: <EZ28Flcza9YEYE_4b-BzQAgXNt8wWU5So2epEysYOoc=.e75f5ef3-5975-4fed-8e1c-b4cf370bba22@github.com>

On Thu, 3 Jul 2025 16:02:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> They have not been updated since jdk8 and are unlikely to be.

not true. They are updated regularly and I expect an enhancement to add some new feature testing some time in the next year.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3033245552

From prr at openjdk.org  Thu Jul  3 18:56:39 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 18:56:39 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <WMl97-WMeXpBz1qZZllxlOfoxsFQsRUJ93ojxMMazQU=.efcc07d8-8f62-4197-8d37-f9011f48ba79@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

and don't get confused about the ant and make stuff. The JDK build does not and is not expected to build j2dbench
It is built directly by a developer when they need to run it. 
I think the ant build was for developers who use certain IDEs.
I tend to use the make option.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3033274247

From prr at openjdk.org  Thu Jul  3 19:33:40 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 19:33:40 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <PGs-ecJTzRCARPURkRS00PECjq946Ylz6gx2QHEUxj0=.c1eab603-494d-46fd-b6d0-56b88a0743a2@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

src/demo/share/java2d/J2DBench/build.xml line 42:

> 40:   <property name="resources"  location="resources"/>
> 41: 
> 42:   <condition property="source" value="8">

This would be inconsistent with the Make target. It doesn't seem right to update just the ant-based target.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26077#discussion_r2183618460

From prr at openjdk.org  Thu Jul  3 19:34:43 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 19:34:43 GMT
Subject: RFR: 8361213: J2DAnalyzer should emit the score as a decimal [v2]
In-Reply-To: <VfcPiMICDwRoZ_h2UIygFu6VW9qhmwFyN65v7BQ8gI8=.02e0456a-f625-47d1-91e7-55b0f6f3c344@github.com>
References: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
 <VfcPiMICDwRoZ_h2UIygFu6VW9qhmwFyN65v7BQ8gI8=.02e0456a-f625-47d1-91e7-55b0f6f3c344@github.com>
Message-ID: <zl3MVUKnSgu8VOJr6Hb0-fddcAe2OoH_9acFha22Cqs=.978783c2-2402-42d5-a284-468ccb4258ac@github.com>

On Wed, 2 Jul 2025 18:56:33 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> As mentioned in the bug, I think it would be better to always emit the score as decimal instead of sometimes decimal, sometimes scientific notation.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use - to left-align the result

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26076#pullrequestreview-2984448348

From prr at openjdk.org  Thu Jul  3 19:35:41 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 19:35:41 GMT
Subject: RFR: 8361115: javax/swing/JComboBox/bug4276920.java unnecessarily
 throws Error instead of RuntimeException
In-Reply-To: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>
References: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>
Message-ID: <VrEDBRCQiR6AacUWHLubl8GcoTD1fL9UsqHAAvX1-KY=.f6a0e657-4d9e-497a-b5c4-1d67ac3e6633@github.com>

On Tue, 1 Jul 2025 04:57:05 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/JComboBox/bug4276920.java unnecessarily throws Error instead of RuntimeException whenever a test failure occurs.
> This causes unnecessary extra attention in CI systems and triggers task failures as throwing an Error will write the error message to System.err and the CI system will detect it as an 'Error' and fails the task eventually.
> But this is just a normal test failure only and just need to throw 'RuntimeException' and no need to throw an 'Error'.
> 
> Fix:
> Replace 'Error' with 'RuntimeException'
> 
> Testing:
> Tested using mach5 in all the available platforms.
> Tested manually the negative (failure) condition also and verified that its throwing 'RuntimeException' in cases of failure.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26056#pullrequestreview-2984449498

From duke at openjdk.org  Thu Jul  3 19:39:40 2025
From: duke at openjdk.org (duke)
Date: Thu, 3 Jul 2025 19:39:40 GMT
Subject: RFR: 8361115: javax/swing/JComboBox/bug4276920.java unnecessarily
 throws Error instead of RuntimeException
In-Reply-To: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>
References: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>
Message-ID: <Je6pCa6_C09bUZb16_n3aY96eQAgXZNW5x6cRUY7e4Y=.8279e5b8-1960-4057-b796-29a804a21c5f@github.com>

On Tue, 1 Jul 2025 04:57:05 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/JComboBox/bug4276920.java unnecessarily throws Error instead of RuntimeException whenever a test failure occurs.
> This causes unnecessary extra attention in CI systems and triggers task failures as throwing an Error will write the error message to System.err and the CI system will detect it as an 'Error' and fails the task eventually.
> But this is just a normal test failure only and just need to throw 'RuntimeException' and no need to throw an 'Error'.
> 
> Fix:
> Replace 'Error' with 'RuntimeException'
> 
> Testing:
> Tested using mach5 in all the available platforms.
> Tested manually the negative (failure) condition also and verified that its throwing 'RuntimeException' in cases of failure.

@manukumarvs 
Your change (at version 4f2a9a0709cb8ae03294262265dedd091337b129) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26056#issuecomment-3033400291

From ecaspole at openjdk.org  Thu Jul  3 19:46:42 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 3 Jul 2025 19:46:42 GMT
Subject: Integrated: 8361213: J2DAnalyzer should emit the score as a decimal
In-Reply-To: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
References: <dKEg371DdXs3fid9NBz18IdNN-r7kIa3T5ZmuLq6meA=.1db1cbd3-b103-454d-9a88-1fee098d53d2@github.com>
Message-ID: <qvXcRwyIALjPRw7nYBomMnlSJoMk98nYGdiL_taatMI=.0e2dbef0-f36d-4ab7-8dc5-a27613d14ead@github.com>

On Tue, 1 Jul 2025 17:38:35 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> As mentioned in the bug, I think it would be better to always emit the score as decimal instead of sometimes decimal, sometimes scientific notation.

This pull request has now been integrated.

Changeset: dcc7254a
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dcc7254a38bb0fecacd7683682d4c42e49335222
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361213: J2DAnalyzer should emit the score as a decimal

Reviewed-by: prr

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

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

From ecaspole at openjdk.org  Thu Jul  3 20:01:47 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 3 Jul 2025 20:01:47 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <PGs-ecJTzRCARPURkRS00PECjq946Ylz6gx2QHEUxj0=.c1eab603-494d-46fd-b6d0-56b88a0743a2@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
 <PGs-ecJTzRCARPURkRS00PECjq946Ylz6gx2QHEUxj0=.c1eab603-494d-46fd-b6d0-56b88a0743a2@github.com>
Message-ID: <AOk2eJ9P6FUqODNFNv4T3qKwRQIRXatrTmHL90YP_YI=.8f2dd469-69a8-4d7a-af89-4e1515c1d134@github.com>

On Thu, 3 Jul 2025 19:30:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.
>
> src/demo/share/java2d/J2DBench/build.xml line 42:
> 
>> 40:   <property name="resources"  location="resources"/>
>> 41: 
>> 42:   <condition property="source" value="8">
> 
> This would be inconsistent with the Make target. It doesn't seem right to update just the ant-based target.

Yes I realized that yesterday, I never actually looked at or used the Makefile before. I will update the Makefile so it least this PR in its own right is consistent, regardless of these other discussion points.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26077#discussion_r2183657821

From dnguyen at openjdk.org  Thu Jul  3 21:09:40 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 3 Jul 2025 21:09:40 GMT
Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for
 Tree in Aqua LAF [v2]
In-Reply-To: <n5rfmWPxCGA_mXnHhRet8epSNGbXD4818LXkaPv45-w=.da7786a4-e259-4f2e-a227-660412250d8d@github.com>
References: <c5QzVaRau-hKMcULFzYUpUupKUtQUzzwRthvBdgxyRs=.06b6de33-9e66-491f-bf28-d6e1a41206af@github.com>
 <n5rfmWPxCGA_mXnHhRet8epSNGbXD4818LXkaPv45-w=.da7786a4-e259-4f2e-a227-660412250d8d@github.com>
Message-ID: <KRBAt8KTfoEtsBjYAIWOevofsW5s3EWprL3NV9azQwY=.2e0df767-1309-4e52-934b-4036cb4ee578@github.com>

On Tue, 24 Jun 2025 12:11:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY).....
>> Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them
>> so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead
>> 
>> No regression test as it can be verified through SwingSet2 demo as below..
>> 
>> With ctrl+shift+down
>> <img width="124" alt="Screenshot 2025-06-19 at 1 41 39?PM" src="https://github.com/user-attachments/assets/8baa386e-b03a-4fd2-b5e2-4ac26157e5af" />
>> 
>> another ctrl+shift+down
>> <img width="127" alt="Screenshot 2025-06-19 at 1 42 39?PM" src="https://github.com/user-attachments/assets/572a806c-4d54-4045-b92a-c1e88d403305" />
>> 
>> Now, ctrl+shift+up
>> <img width="134" alt="Screenshot 2025-06-19 at 1 44 51?PM" src="https://github.com/user-attachments/assets/6d671852-f7b7-434f-8688-6c5dd4b3cdb5" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Since https://github.com/openjdk/jdk/pull/25966 has been integrated, should this PR be closed and the JBS issue closed as "Not an issue"?

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

PR Comment: https://git.openjdk.org/jdk/pull/25892#issuecomment-3033657972

From serb at openjdk.org  Thu Jul  3 21:12:41 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 3 Jul 2025 21:12:41 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <AOk2eJ9P6FUqODNFNv4T3qKwRQIRXatrTmHL90YP_YI=.8f2dd469-69a8-4d7a-af89-4e1515c1d134@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
 <PGs-ecJTzRCARPURkRS00PECjq946Ylz6gx2QHEUxj0=.c1eab603-494d-46fd-b6d0-56b88a0743a2@github.com>
 <AOk2eJ9P6FUqODNFNv4T3qKwRQIRXatrTmHL90YP_YI=.8f2dd469-69a8-4d7a-af89-4e1515c1d134@github.com>
Message-ID: <Hwnb5ZHKomN3i-EZ0fEudxTuBFXLb3ieevtCAnAJxtQ=.b9397cf4-20ed-4a4c-860a-5a6e1fed4ead@github.com>

On Thu, 3 Jul 2025 19:59:26 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> src/demo/share/java2d/J2DBench/build.xml line 42:
>> 
>>> 40:   <property name="resources"  location="resources"/>
>>> 41: 
>>> 42:   <condition property="source" value="8">
>> 
>> This would be inconsistent with the Make target. It doesn't seem right to update just the ant-based target.
>
> Yes I realized that yesterday, I never actually looked at or used the Makefile before. I will update the Makefile so it least this PR in its own right is consistent, regardless of these other discussion points.

I think we can just drop ant and leave the makefile as it is. The source/target settings are set to that low level to indicate that the source code should be compatible with older versions of the JDK. Currently, JDK 1.4 compatibility is still maintained.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26077#discussion_r2183757974

From prr at openjdk.org  Thu Jul  3 21:53:38 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 21:53:38 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <Hwnb5ZHKomN3i-EZ0fEudxTuBFXLb3ieevtCAnAJxtQ=.b9397cf4-20ed-4a4c-860a-5a6e1fed4ead@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
 <PGs-ecJTzRCARPURkRS00PECjq946Ylz6gx2QHEUxj0=.c1eab603-494d-46fd-b6d0-56b88a0743a2@github.com>
 <AOk2eJ9P6FUqODNFNv4T3qKwRQIRXatrTmHL90YP_YI=.8f2dd469-69a8-4d7a-af89-4e1515c1d134@github.com>
 <Hwnb5ZHKomN3i-EZ0fEudxTuBFXLb3ieevtCAnAJxtQ=.b9397cf4-20ed-4a4c-860a-5a6e1fed4ead@github.com>
Message-ID: <-NYImJ94f_X6FR6wgZDfzdzA53dfZbEx8EzeBA5GZ3A=.e43f155f-0d0e-4f66-b0c9-73e7f10beddb@github.com>

On Thu, 3 Jul 2025 21:09:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think we can just drop ant and leave the makefile as it is. The source/target settings are set to that low level to indicate that the source code should be compatible with older versions of the JDK. Currently, JDK 1.4 compatibility is still maintained.

I have supposed that this PR exists because Eric wants to use ant. Eric ?

I think for today's mainline, not supporting jdk7 as an out of the box target isn't a huge problem. 
Current javac doesn't support 7 as a target so it seems reasonable to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26077#discussion_r2183801786

From prr at openjdk.org  Thu Jul  3 22:09:40 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 22:09:40 GMT
Subject: RFR: 8360120: Bundled macOS applications not receiving OpenURL
 events when launched as subprocess [v2]
In-Reply-To: <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com>
References: <uWgL0eCGLxkGigE-IPkEgbq2i3t-dHmAyyPmedZrgFA=.8ff131f6-bc00-4a1e-ada2-99346bae1220@github.com>
 <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com>
Message-ID: <mMQ5y9wvbqlceTKcMnlTVMAnbBTUTulVufqpYJxvvgg=.6e1e5a03-920a-429b-9d9c-8a41505adf41@github.com>

On Wed, 25 Jun 2025 07:03:33 GMT, Dmitry Kulikov <duke at openjdk.org> wrote:

>> Added an on-demand installation of the native OpenURL event handler to the `Application.setOpenURIHandler()`.
>> 
>> This does not break the specification for the affected API, since the requirement of the application being bundled and containing `CFBundleURLTypes` in the `Info.plist` is still valid: macOS will neither launch nor send OpenURL events to an application that does not declare such capabilities it the bundle.
>> 
>> Running tests on macOS showed no regressions after this patch. Other platforms are not affected.
>
> Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

Let me try to understand this. 

[1] On startup, if it is a bundled application (per macOS rules) JDK will currently install a *native* handler,
even though [2] nothing in the Java code may actually be installed to handle it ?
ie the startup code, does it "just in case" ...
[3] And unless the native handler is installed, macOS will never ask the app to handle the URL.

Now the Java app doesn't actually care about no native handler ie [3] unless it calls setOpenURIHandler(), unless macOS has some built-in default that might be useful - but I doubt that.

Once the Java app does call setOpenURIHandler() it would clearly like to have its handler called - although according to what you say - macOS will still only do that if it is a bundled app.

At this point if no native handler is installed by [1], your change will install it, so from then on macOS will - for a bundled app - start sending it messages.

What I am getting out of this is that 
(a) the installation of the native handler during startup is arguably pointless and we should always just install it when we know its needed - as in this change
(b) the checks that start up does are pointless
I'm guessing for "safety" you decided to leave those alone ?
But I'm not sure if these are really equivalent. 
I don't know how  [bundle _hasEAWTOverride:@"URLHandler"] is accounted for or whether it matters.
I am probably missing a key piece, but it seems to be an alternative way to get macOS to send messages,
but if that's the case, I don't know why it matters at all whether we check and whether Apple still support it.
Is there a possibility of a regression test here ? I'm guessing it would be might hardy but I've got to ask.

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

PR Comment: https://git.openjdk.org/jdk/pull/25967#issuecomment-3033810216

From prr at openjdk.org  Thu Jul  3 22:13:41 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 22:13:41 GMT
Subject: RFR: 6955128: Spec for
 javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate
 wording [v3]
In-Reply-To: <BXNW3XNV5G6bFg70V0RYq1VOHPVhLaATzzSiSsBWB9M=.25f7492d-2a61-4232-869c-e037fa4b6ce7@github.com>
References: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
 <BXNW3XNV5G6bFg70V0RYq1VOHPVhLaATzzSiSsBWB9M=.25f7492d-2a61-4232-869c-e037fa4b6ce7@github.com>
Message-ID: <N1CotI3J0XCzsZCAgK2cflNlzHPkxxudjHGN4roAtgA=.212b9b18-9cc2-4bc2-9770-6b81ec8cbd71@github.com>

On Wed, 25 Jun 2025 12:15:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named".
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update javadoc
>  - Update javadoc

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1032:

> 1030: 
> 1031:     /**
> 1032:      * Gets the allocation for the root view.

What I've been asking for is something like
"Gets the allocation (i.e. the allocated size) for the root view."

A CSR doesn't seem strictly necessary but I recommend one anyway

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2183844029

From prr at openjdk.org  Thu Jul  3 22:29:40 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 3 Jul 2025 22:29:40 GMT
Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile [v2]
In-Reply-To: <MBG1m2GX7FPstoub0zmIorfDU1XjSswJZueqjF8An2g=.e07f0847-2a2d-41d4-9bda-d261fa52acd0@github.com>
References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com>
 <MBG1m2GX7FPstoub0zmIorfDU1XjSswJZueqjF8An2g=.e07f0847-2a2d-41d4-9bda-d261fa52acd0@github.com>
Message-ID: <f-AF_5L3Opb-tqP6q1BKJMfHu5SOPlXH5Xf3OsTH4Bg=.d2e27b3a-b234-4205-a99e-34923616732e@github.com>

On Fri, 13 Jun 2025 20:24:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This PR simplifies several aspects of the ICC_Profile class:
>> 
>> - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30):
>>     The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377).
>> 
>> - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe):
>>     In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation.
>> 
>>  - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c):
>> After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code.
>> 
>> @prrace @honkar-jdk please take a look
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   theHeader -> data

This looks OK to me.  I see @honkar-jdk says CI testing has already been done.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25650#pullrequestreview-2984867185

From mvs at openjdk.org  Thu Jul  3 22:34:43 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Thu, 3 Jul 2025 22:34:43 GMT
Subject: Integrated: 8361115: javax/swing/JComboBox/bug4276920.java
 unnecessarily throws Error instead of RuntimeException
In-Reply-To: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>
References: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>
Message-ID: <OjN1iHrZQZrpfDubfCIdvbTYg30sdvZY63wgw_JbDwE=.7fa637cd-3cfb-472f-a88a-7a8593b39a5c@github.com>

On Tue, 1 Jul 2025 04:57:05 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/JComboBox/bug4276920.java unnecessarily throws Error instead of RuntimeException whenever a test failure occurs.
> This causes unnecessary extra attention in CI systems and triggers task failures as throwing an Error will write the error message to System.err and the CI system will detect it as an 'Error' and fails the task eventually.
> But this is just a normal test failure only and just need to throw 'RuntimeException' and no need to throw an 'Error'.
> 
> Fix:
> Replace 'Error' with 'RuntimeException'
> 
> Testing:
> Tested using mach5 in all the available platforms.
> Tested manually the negative (failure) condition also and verified that its throwing 'RuntimeException' in cases of failure.

This pull request has now been integrated.

Changeset: 16af4733
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16af473397a7b3a6e6e33dd684d0d511168b989b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8361115: javax/swing/JComboBox/bug4276920.java unnecessarily throws Error instead of RuntimeException

Reviewed-by: prr

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

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

From honkar at openjdk.org  Thu Jul  3 22:43:40 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 3 Jul 2025 22:43:40 GMT
Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile [v2]
In-Reply-To: <MBG1m2GX7FPstoub0zmIorfDU1XjSswJZueqjF8An2g=.e07f0847-2a2d-41d4-9bda-d261fa52acd0@github.com>
References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com>
 <MBG1m2GX7FPstoub0zmIorfDU1XjSswJZueqjF8An2g=.e07f0847-2a2d-41d4-9bda-d261fa52acd0@github.com>
Message-ID: <9s13Tr6KAyWkmxKzkJfZtlL8K37h2FqKjYCZXKPhvjY=.d7303182-c7af-460b-bce4-5d114a25f853@github.com>

On Fri, 13 Jun 2025 20:24:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This PR simplifies several aspects of the ICC_Profile class:
>> 
>> - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30):
>>     The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377).
>> 
>> - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe):
>>     In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation.
>> 
>>  - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c):
>> After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code.
>> 
>> @prrace @honkar-jdk please take a look
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   theHeader -> data

Marked as reviewed by honkar (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25650#pullrequestreview-2984882524

From honkar at openjdk.org  Thu Jul  3 22:43:40 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 3 Jul 2025 22:43:40 GMT
Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile [v2]
In-Reply-To: <f-AF_5L3Opb-tqP6q1BKJMfHu5SOPlXH5Xf3OsTH4Bg=.d2e27b3a-b234-4205-a99e-34923616732e@github.com>
References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com>
 <MBG1m2GX7FPstoub0zmIorfDU1XjSswJZueqjF8An2g=.e07f0847-2a2d-41d4-9bda-d261fa52acd0@github.com>
 <f-AF_5L3Opb-tqP6q1BKJMfHu5SOPlXH5Xf3OsTH4Bg=.d2e27b3a-b234-4205-a99e-34923616732e@github.com>
Message-ID: <eTts6Ezsx0IDDgcUX9bVTYJwQRUAiagq3Dcg7xbl_CA=.18fa3680-383f-41b7-af41-04e027da4b7f@github.com>

On Thu, 3 Jul 2025 22:27:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   theHeader -> data
>
> This looks OK to me.  I see @honkar-jdk says CI testing has already been done.

@prrace 
> I see @honkar-jdk says CI testing has already been done.

Yes, the CI testing looks good for this PR changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25650#issuecomment-3033873700

From honkar at openjdk.org  Thu Jul  3 22:53:00 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 3 Jul 2025 22:53:00 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v22]
In-Reply-To: <Hzte_IUFOGKwJ7th5xZPB-o8J8AqopfRzRFd3OYb0j4=.7875621f-2879-4c9b-be2a-65f3c49b91a5@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <Hzte_IUFOGKwJ7th5xZPB-o8J8AqopfRzRFd3OYb0j4=.7875621f-2879-4c9b-be2a-65f3c49b91a5@github.com>
Message-ID: <YVr1gBvjIzlJ86OedZUqbcJKAxXLiPpUObXzk-m-Xlw=.a38305fe-e640-4c08-8964-bffba15626e9@github.com>

On Thu, 3 Jul 2025 15:55:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ER from remaining modal test

Latest changes LGTM. 

@alisenchung 
Does CI run look good with the latest changes?

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

PR Review: https://git.openjdk.org/jdk/pull/22044#pullrequestreview-2984901578

From honkar at openjdk.org  Thu Jul  3 22:58:58 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 3 Jul 2025 22:58:58 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v22]
In-Reply-To: <Bh79pvpzCXBNlepXMV9xoQusoCfJqMMMzLaBad3kbhk=.dfabb978-e641-4715-a865-08c5fc2a78d0@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <a54rX4IMCzg8lzHGBeY1Na1AzbKx6UuKU5NAofbQp7A=.4da151e6-d624-47ed-a179-05569a53c055@github.com>
 <Bh79pvpzCXBNlepXMV9xoQusoCfJqMMMzLaBad3kbhk=.dfabb978-e641-4715-a865-08c5fc2a78d0@github.com>
Message-ID: <ftI8O2-CDtONhZ0TFsGbTTs6Z0l9H5v-P3b3ASWF5hw=.6b3ece35-82ad-449a-b1a8-59753dbaee5a@github.com>

On Tue, 17 Jun 2025 16:47:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove ER from remaining modal test
>
> test/jdk/java/awt/TrayIcon/TrayIconPopup/TrayIconPopupTest.java line 56:
> 
>> 54:  *          jdk.test.lib.Platform
>> 55:  *          jtreg.SkippedException
>> 56:  *          ExtendedRobot
> 
> Since ExtendedRobot is removed /lib/client is no longer required in `@library` tag. Applicable for other tests as well.

There are couple of tests with /lib/client in `@library` tag which is no longer required. This cleanup can be handled in subsequent PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2183892257

From serb at openjdk.org  Fri Jul  4 01:00:22 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 4 Jul 2025 01:00:22 GMT
Subject: RFR: 8358623: Avoid unnecessary data copying in ICC_Profile [v3]
In-Reply-To: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com>
References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com>
Message-ID: <h1CM9PTF8xpaqMImx9oKE1GQniSuClMc-x40tu8Wkwk=.90a8a855-d9b4-4864-b138-c7a5591b6f66@github.com>

> This PR simplifies several aspects of the ICC_Profile class:
> 
> - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30):
>     The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377).
> 
> - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe):
>     In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation.
> 
>  - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c):
> After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code.
> 
> @prrace @honkar-jdk please take a look

Sergey Bylokhov 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 eight additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8358623
 - theHeader -> data
 - Update CheckVersions.java
 - Create CheckVersions.java
 - ICC -> CMM
 - Eliminate possible NPE when getData is used
 - Replace  getData(icSigHead) by the getData(cmmProfile(), icSigHead)
 - Avoid arraycopy in getInstance(byte[])

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25650/files
  - new: https://git.openjdk.org/jdk/pull/25650/files/97d01fc3..ec1165d8

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

  Stats: 51198 lines in 1483 files changed: 30467 ins; 13841 del; 6890 mod
  Patch: https://git.openjdk.org/jdk/pull/25650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25650/head:pull/25650

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

From serb at openjdk.org  Fri Jul  4 01:01:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 4 Jul 2025 01:01:51 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <-NYImJ94f_X6FR6wgZDfzdzA53dfZbEx8EzeBA5GZ3A=.e43f155f-0d0e-4f66-b0c9-73e7f10beddb@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
 <PGs-ecJTzRCARPURkRS00PECjq946Ylz6gx2QHEUxj0=.c1eab603-494d-46fd-b6d0-56b88a0743a2@github.com>
 <AOk2eJ9P6FUqODNFNv4T3qKwRQIRXatrTmHL90YP_YI=.8f2dd469-69a8-4d7a-af89-4e1515c1d134@github.com>
 <Hwnb5ZHKomN3i-EZ0fEudxTuBFXLb3ieevtCAnAJxtQ=.b9397cf4-20ed-4a4c-860a-5a6e1fed4ead@github.com>
 <-NYImJ94f_X6FR6wgZDfzdzA53dfZbEx8EzeBA5GZ3A=.e43f155f-0d0e-4f66-b0c9-73e7f10beddb@github.com>
Message-ID: <Z3Za8Q1MvHz681H5rULDJhiN6FNv6SX-Yy-hoZJUF80=.01387b02-a3a8-494e-9f95-0274205ce505@github.com>

On Thu, 3 Jul 2025 21:50:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Current javac doesn't support 7 as a target so it seems reasonable to me.

That's why the makefile was parameterized, to easily set the target and source options based on the currently used minimal supported version of javac. But we may change it with a comment that 1.4 still should be supported, or something like that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26077#discussion_r2184015227

From psadhukhan at openjdk.org  Fri Jul  4 03:09:32 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 4 Jul 2025 03:09:32 GMT
Subject: RFR: 6955128: Spec for
 javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate
 wording [v4]
In-Reply-To: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
References: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
Message-ID: <PgSFZan2PtuaHhX91SOzfszJnt-i7dRotDjqSX-4_Hs=.3cf4d27f-ca3e-4b06-b6e6-a01a1485b9ca@github.com>

> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named".

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Update javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25850/files
  - new: https://git.openjdk.org/jdk/pull/25850/files/6289a27a..4cd9caff

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

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

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

From psadhukhan at openjdk.org  Fri Jul  4 03:17:39 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 4 Jul 2025 03:17:39 GMT
Subject: RFR: 6955128: Spec for
 javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate
 wording [v3]
In-Reply-To: <N1CotI3J0XCzsZCAgK2cflNlzHPkxxudjHGN4roAtgA=.212b9b18-9cc2-4bc2-9770-6b81ec8cbd71@github.com>
References: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
 <BXNW3XNV5G6bFg70V0RYq1VOHPVhLaATzzSiSsBWB9M=.25f7492d-2a61-4232-869c-e037fa4b6ce7@github.com>
 <N1CotI3J0XCzsZCAgK2cflNlzHPkxxudjHGN4roAtgA=.212b9b18-9cc2-4bc2-9770-6b81ec8cbd71@github.com>
Message-ID: <y9Jku5ORLfQJFLnRBj4zYVHq2XrHva12iBnz1TVBMrg=.9190a98d-f435-494c-a9a1-5e7c20a28296@github.com>

On Thu, 3 Jul 2025 22:11:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update javadoc
>>  - Update javadoc
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1032:
> 
>> 1030: 
>> 1031:     /**
>> 1032:      * Gets the allocation for the root view.
> 
> What I've been asking for is something like
> "Gets the allocation (i.e. the allocated size) for the root view."
> 
> A CSR doesn't seem strictly necessary but I recommend one anyway

Updated.
CSR raised https://bugs.openjdk.org/browse/JDK-8361384

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2184212352

From psadhukhan at openjdk.org  Fri Jul  4 03:27:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 4 Jul 2025 03:27:17 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v32]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <HGe0L_ed0DCz9hgDrMt1TZtGTYtJKxvf7EZB336uhD8=.47a17675-dac3-4cf5-b1eb-9a1e4b051d72@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  squish fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/24fb8195..fcaeb2d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=30-31

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

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

From psadhukhan at openjdk.org  Fri Jul  4 03:27:17 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 4 Jul 2025 03:27:17 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <ihbtQ4a1zeDU1dgZ9UNHKacuK-9HB7Yxg73_yAVBNrI=.c5e3236b-e113-4670-b03d-02bb49083736@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com>
 <jTfs-ve48402p333JuIyOnJjFoKqwNaUJa45_du_zu8=.5abcab29-f372-488e-853c-014ebc14dc7d@github.com>
 <QFetdv19Jeuk2nIJ5jG8Ju6dc8fJvADjILW9P0UN9Ts=.19ac45fa-5170-4cc2-bf11-2edd690273c3@github.com>
 <LQrOMe-aKNLvLvivFzUe2HyHCjz3J2TocWEchAwoQ7E=.d64bc1ee-3f77-40a7-976c-3f88a7fb68d6@github.com>
 <ihbtQ4a1zeDU1dgZ9UNHKacuK-9HB7Yxg73_yAVBNrI=.c5e3236b-e113-4670-b03d-02bb49083736@github.com>
Message-ID: <55aysCZXurqsNGOCzpY51V5H6L-KTnrTHyNyZWR0D_E=.3ef2c49b-9323-4604-8bf0-75515c7b9097@github.com>

On Mon, 30 Jun 2025 13:21:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> As I said, I didn't look deeply into the details.
>> 
>> The menu layout already implements a 5-column layout ? this is what I expect because both Metal and Nimbus look exactly like a 5-column layout. Yet Windows L&F is still off, and the margins and offsets don't match what one sees in File Explorer in Windows 11.
>
> After your latest fix, the accelerator doesn't get painted over the menu text, but the positioning is still way off.
> 
> With the added column for the icon the menu width has to increase but it hasn't. Instead, the width remains the same, and you squeeze both check mark / bullet and icon to the same allocated space.
> 
> The position of the check mark must not change in the new layout. In old rendering code, the was 29-pixel margin between the left edge and first pixel of the check mark (at 200% scale), but now it's reduced to 23 pixels only.
> 
> There was 24-pixel margin between an icon and text, but now it's only 6 pixels.
> 
> The margin between menu text and accelerator is reduced from 12 pixels to 4.
> 
> The menu looks too crowded, squished. You have to properly add *a new column for the icon* with margins around it whenever a popup menu has a JCheckBoxMenuItem or JRadioButtonMenuItem with an icon.

I guess the positioning with latest PR today should be ok

![image](https://github.com/user-attachments/assets/f54247e8-6cbc-4b63-972f-90a155d5bbc1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2184224118

From abhiscxk at openjdk.org  Fri Jul  4 08:25:39 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 4 Jul 2025 08:25:39 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <wTeXhDNJZEgv6Gj-sCzqynznZEZtg7_Q2mcZp4SW308=.6494902f-e7b0-49da-be3b-667af7ccbe9a@github.com>

On Fri, 20 Jun 2025 03:09:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 92:

> 90:         JMenuBar menuBar = new JMenuBar();
> 91: 
> 92:         menuBar.add(createMenu("javax.swing.plaf.metal.MetalLookAndFeel",

I tried to extend the test (with this PR changes included) for all installed L&Fs and then create the menu for each L&F. 

        UIManager.LookAndFeelInfo[] lafs = UIManager.getInstalledLookAndFeels();
        for (final UIManager.LookAndFeelInfo lafInfo : lafs) {
            System.out.println("installed laf className : " + lafInfo.getClassName());
            System.out.println("installed laf Name : " + lafInfo.getName());
            menuBar.add(createMenu(lafInfo.getClassName(), lafInfo.getName()));
        }

Then the test failed with this exception 

        java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null
	at java.desktop/sun.font.FontDesignMetrics$MetricsKey.init(FontDesignMetrics.java:213)
	at java.desktop/sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:282)
	at java.desktop/sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1235)

Otherwise the RBMI and CBMI does contain the icon after the fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2184710678

From abhiscxk at openjdk.org  Fri Jul  4 08:35:39 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 4 Jul 2025 08:35:39 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <VNJN8piq9i4obYrXFxzUpJZSmBJyS2R5aCsfE0Ntzxo=.375be7b8-71cc-49d2-8619-6ced5df45704@github.com>

On Fri, 20 Jun 2025 03:09:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

One more thing I observed is "If we change the order of menu creation" then the icons rendered are different.
For e.g. if the order is

    menuBar.add(createMenu("javax.swing.plaf.metal.MetalLookAndFeel",
                "Metal"));
        menuBar.add(createMenu("com.sun.java.swing.plaf.windows.WindowsLookAndFeel",
                "Windows"));
        menuBar.add(createMenu("com.sun.java.swing.plaf.motif.MotifLookAndFeel",
                "Motif"));

then the icons are 
![Windows_Second_Pos](https://github.com/user-attachments/assets/81efec22-b3b2-48e2-a31b-f095c8ec4c3f)

and when Windows L&F is at last pos then rendered icons are
![Windows_Last_Pos](https://github.com/user-attachments/assets/6b13bfb8-c319-4344-afd7-26584f3a2056)

Shouldn't the icons for the L&Fs be same ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3034978507

From abhiscxk at openjdk.org  Fri Jul  4 08:42:40 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 4 Jul 2025 08:42:40 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <4qiFyjj56YqWJc3cBWcJLOyfPrRO79Jn_OD2VKLxkIc=.02576f51-99c7-4e80-9b20-e7172ff1d94e@github.com>

On Fri, 20 Jun 2025 03:09:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 1:

> 1: /*

Don't think it is required in the summary `The tester is asked to compare left-to-right and right-to-left menus and judge whether they are mirror images of each other.`, it is mentioned in instruction.

Not mandatory but still for consistency, you can move `This test checks if menu items lay out correctly when their` on the same line as `@summary`.

@summary This test checks if menu items lay out correctly when their

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2184746651

From mvs at openjdk.org  Fri Jul  4 09:33:17 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Fri, 4 Jul 2025 09:33:17 GMT
Subject: [jdk25] RFR: 8359889: java/awt/MenuItem/SetLabelTest.java
 inadvertently triggers clicks on items pinned to the taskbar
Message-ID: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>

This is the backport of a test stabilisation fix done by @manukumarvs and approved by @aivanov-jdk.

Issue:
In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine.

Fix:
Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null).

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

Commit messages:
 - Backport b7fcd0b2351cee8d3d18abaf0bf5905d20c9d46c

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

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

From aivanov at openjdk.org  Fri Jul  4 09:57:40 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 4 Jul 2025 09:57:40 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <wTeXhDNJZEgv6Gj-sCzqynznZEZtg7_Q2mcZp4SW308=.6494902f-e7b0-49da-be3b-667af7ccbe9a@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <wTeXhDNJZEgv6Gj-sCzqynznZEZtg7_Q2mcZp4SW308=.6494902f-e7b0-49da-be3b-667af7ccbe9a@github.com>
Message-ID: <ly2FkzpWSs7f9Ez1GIz9dSydW6rIkjDZzd0WcuN49WA=.57be179b-a885-4881-9cda-acbfbbf426ee@github.com>

On Fri, 4 Jul 2025 08:20:27 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
>> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
>> 
>> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..
>
> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 92:
> 
>> 90:         JMenuBar menuBar = new JMenuBar();
>> 91: 
>> 92:         menuBar.add(createMenu("javax.swing.plaf.metal.MetalLookAndFeel",
> 
> I tried to extend the test (with this PR changes included) for all installed L&Fs and then create the menu for each L&F. 
> 
>         UIManager.LookAndFeelInfo[] lafs = UIManager.getInstalledLookAndFeels();
>         for (final UIManager.LookAndFeelInfo lafInfo : lafs) {
>             System.out.println("installed laf className : " + lafInfo.getClassName());
>             System.out.println("installed laf Name : " + lafInfo.getName());
>             menuBar.add(createMenu(lafInfo.getClassName(), lafInfo.getName()));
>         }
> 
> Then the test failed with this exception 
> 
>         java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null
> 	at java.desktop/sun.font.FontDesignMetrics$MetricsKey.init(FontDesignMetrics.java:213)
> 	at java.desktop/sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:282)
> 	at java.desktop/sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1235)
> 
> Otherwise the RBMI and CBMI does contain the icon after the fix.

This is similar to the exception that I got [above](https://github.com/openjdk/jdk/pull/25907#issuecomment-3001288429). It's just a result of mixing several L&Fs at the same time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2184908197

From abhiscxk at openjdk.org  Fri Jul  4 10:09:40 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 4 Jul 2025 10:09:40 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <ly2FkzpWSs7f9Ez1GIz9dSydW6rIkjDZzd0WcuN49WA=.57be179b-a885-4881-9cda-acbfbbf426ee@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <wTeXhDNJZEgv6Gj-sCzqynznZEZtg7_Q2mcZp4SW308=.6494902f-e7b0-49da-be3b-667af7ccbe9a@github.com>
 <ly2FkzpWSs7f9Ez1GIz9dSydW6rIkjDZzd0WcuN49WA=.57be179b-a885-4881-9cda-acbfbbf426ee@github.com>
Message-ID: <OrbtyTWsBj_l8sgjjl8hpx3wb_sT73n3EUNHNCzQZ54=.e36da3c8-35af-411c-8167-a03456e5f67c@github.com>

On Fri, 4 Jul 2025 09:54:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 92:
>> 
>>> 90:         JMenuBar menuBar = new JMenuBar();
>>> 91: 
>>> 92:         menuBar.add(createMenu("javax.swing.plaf.metal.MetalLookAndFeel",
>> 
>> I tried to extend the test (with this PR changes included) for all installed L&Fs and then create the menu for each L&F. 
>> 
>>         UIManager.LookAndFeelInfo[] lafs = UIManager.getInstalledLookAndFeels();
>>         for (final UIManager.LookAndFeelInfo lafInfo : lafs) {
>>             System.out.println("installed laf className : " + lafInfo.getClassName());
>>             System.out.println("installed laf Name : " + lafInfo.getName());
>>             menuBar.add(createMenu(lafInfo.getClassName(), lafInfo.getName()));
>>         }
>> 
>> Then the test failed with this exception 
>> 
>>         java.lang.NullPointerException: Cannot invoke "java.awt.Font.hashCode()" because "font" is null
>> 	at java.desktop/sun.font.FontDesignMetrics$MetricsKey.init(FontDesignMetrics.java:213)
>> 	at java.desktop/sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:282)
>> 	at java.desktop/sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1235)
>> 
>> Otherwise the RBMI and CBMI does contain the icon after the fix.
>
> This is similar to the exception that I got [above](https://github.com/openjdk/jdk/pull/25907#issuecomment-3001288429). It's just a result of mixing several L&Fs at the same time.

Yes but it was not supposed to come when `SwingUtilities.updateComponentTreeUI(frame)` is used to update all UI components.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2184932515

From aivanov at openjdk.org  Fri Jul  4 10:17:40 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 4 Jul 2025 10:17:40 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <nCQcpl2D6zs2UI-E5_vNFzOGsM4N9d7mobkGFm1E3t8=.dda9b07c-5afc-46e0-98a9-360652280c68@github.com>

On Fri, 20 Jun 2025 03:09:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

> One more thing I observed is "If we change the order of menu creation" then the icons rendered are different. For e.g. if the order is
> 
> Shouldn't the icons for the L&Fs be same ?

That's the purpose of the test but it fails to test it.

You've just found another proof that multiple L&Fs can't be used concurrently. I've been talking about it since [the very start of this code review](https://github.com/openjdk/jdk/pull/25907#pullrequestreview-2953647827).

When you change L&F, all the `UIDefaults` of the old L&F are removed and values for the newly installed L&F are added.

If a component or its UI doesn't store a setting, such as color, font or icon, in its field, the setting is retrieved from `UIDefaults` ? but the values are different now.

This is what happens in the current test without any changes. After Windows L&F is installed, the L&F is switched back to the whatever L&F was initially. As the result, there are no check marks and bullets in Windows L&F.

The test has to re-create its UI after testing for a L&F is complete. Such a scenario isn't supported by `PassFailJFrame` at the moment, see [JDK-8357455](https://bugs.openjdk.org/browse/JDK-8357455) and https://github.com/openjdk/jdk/pull/24439#discussion_r2100038079. There's no easy workaround.

The test doesn't receive events from `PassFailJFrame`, so the needs to be a custom UI, or the test should be run several times for different L&Fs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3035368348

From aivanov at openjdk.org  Fri Jul  4 10:28:39 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 4 Jul 2025 10:28:39 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <OrbtyTWsBj_l8sgjjl8hpx3wb_sT73n3EUNHNCzQZ54=.e36da3c8-35af-411c-8167-a03456e5f67c@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <wTeXhDNJZEgv6Gj-sCzqynznZEZtg7_Q2mcZp4SW308=.6494902f-e7b0-49da-be3b-667af7ccbe9a@github.com>
 <ly2FkzpWSs7f9Ez1GIz9dSydW6rIkjDZzd0WcuN49WA=.57be179b-a885-4881-9cda-acbfbbf426ee@github.com>
 <OrbtyTWsBj_l8sgjjl8hpx3wb_sT73n3EUNHNCzQZ54=.e36da3c8-35af-411c-8167-a03456e5f67c@github.com>
Message-ID: <wZ22o2rly2xA9wQx0iOemZvRy3cRYKQ0o2UhyjU_JOE=.97851c02-8dda-4f42-befe-232bf624f108@github.com>

On Fri, 4 Jul 2025 10:06:51 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Yes but it was not supposed to come when SwingUtilities.updateComponentTreeUI(frame) is used to update all UI components.

Why not?

In fact, I expected that all the menu items would switch to the latest L&F after updating the component tree.

But it doesn't happen? because the menu bar isn't part of the component hierarchy (yet). If you move the call `frame.setJMenuBar(menuBar)` before each L&F menu is created, all the popup menus are displayed in Windows L&F, the latest installed L&F.

Either way, the test doesn't work correctly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2184983021

From aivanov at openjdk.org  Fri Jul  4 11:05:44 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 4 Jul 2025 11:05:44 GMT
Subject: RFR: 6955128: Spec for
 javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate
 wording [v4]
In-Reply-To: <PgSFZan2PtuaHhX91SOzfszJnt-i7dRotDjqSX-4_Hs=.3cf4d27f-ca3e-4b06-b6e6-a01a1485b9ca@github.com>
References: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
 <PgSFZan2PtuaHhX91SOzfszJnt-i7dRotDjqSX-4_Hs=.3cf4d27f-ca3e-4b06-b6e6-a01a1485b9ca@github.com>
Message-ID: <TtGmAzzzepYawEkAiA9j19sRxazQma3l36c6Bq5_Ik0=.b20021a4-c7b3-44ce-bef5-2468827a5842@github.com>

On Fri, 4 Jul 2025 03:09:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named".
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadoc

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java line 1032:

> 1030: 
> 1031:     /**
> 1032:      * Gets the allocation (i.e. the allocated size) for the root view.

> What I've been asking for is something like\
> "Gets the allocation (i.e. the allocated size) for the root view."

"Gets the allocation (i.e. the size) for the root view."

@prrace Does it sound better?

The [style guide](https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#styleguide) for writing javadoc says:

> **Avoid Latin**
> 
> use "also known as" instead of "aka", use "that is" or "to be specific" instead of "i.e.", use "for example" instead of "e.g.", and use "in other words" or "namely" instead of "viz."

Taking the style guide into account, the text should change to

Suggestion:

     * Gets the allocation (that is the allocated size) for the root view.


I still don't like repeating _?allocated?_, does it clarify the meaning of just _?the size?_?

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

PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-2986680868
PR Review Comment: https://git.openjdk.org/jdk/pull/25850#discussion_r2185065187

From psadhukhan at openjdk.org  Fri Jul  4 12:09:38 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 4 Jul 2025 12:09:38 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <Ou0gfoVOGOIyiyF36DLtRL2mPLkawx09x8R4XAd-K94=.5f78d479-b0bd-4c95-b472-c93f483b041c@github.com>

On Fri, 20 Jun 2025 03:09:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

> The test has to re-create its UI after testing for a L&F is complete. Such a scenario isn't supported by `PassFailJFrame` at the moment, see [JDK-8357455](https://bugs.openjdk.org/browse/JDK-8357455) and [#24439 (comment)](https://github.com/openjdk/jdk/pull/24439#discussion_r2100038079). There's no easy workaround.
> 
> The test doesn't receive events from `PassFailJFrame`, so the needs to be a custom UI, or the test should be run several times for different L&Fs.

So do you propose to test like what is being done in https://github.com/openjdk/jdk/pull/24439/files passing L&F argument to jtreg tag?

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

PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3035935556

From aturbanov at openjdk.org  Fri Jul  4 12:20:40 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 4 Jul 2025 12:20:40 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
Message-ID: <bUnm1jDg5kfel4_Dq0uBeJJOwioHxf229piUp3PviL4=.9b36358b-cf42-419a-8378-cb516390ae9a@github.com>

On Wed, 2 Jul 2025 15:37:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> **Issue** : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
>> 
>> **Analysis** : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
>> 
>> **Proposed Fix** : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.
>> 
>> **Testing** : Manual test case has been added to verify the fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

test/jdk/javax/accessibility/JTabbedPane/AccessibleTabbedPaneRoleTest.java line 74:

> 72:         tabPane.setTabLayoutPolicy(JTabbedPane.SCROLL_TAB_LAYOUT);
> 73:         tabPane.setTabPlacement(JTabbedPane.TOP);
> 74:         for( int i = 0; i < NUM_TABS; ++i) {

Suggestion:

        for (int i = 0; i < NUM_TABS; ++i) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2185219013

From ihse at openjdk.org  Fri Jul  4 12:33:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 4 Jul 2025 12:33:38 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <WMl97-WMeXpBz1qZZllxlOfoxsFQsRUJ93ojxMMazQU=.efcc07d8-8f62-4197-8d37-f9011f48ba79@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
 <WMl97-WMeXpBz1qZZllxlOfoxsFQsRUJ93ojxMMazQU=.efcc07d8-8f62-4197-8d37-f9011f48ba79@github.com>
Message-ID: <chnJR0hLvzH1mKog1bDmf3Ul4Ob2HiAGaMpkeDJKRoM=.07d91fe8-1ea1-4293-a150-e265adc4d5d6@github.com>

On Thu, 3 Jul 2025 18:54:12 GMT, Phil Race <prr at openjdk.org> wrote:

> and don't get confused about the ant and make stuff. The JDK build does not and is not expected to build j2dbench
> It is built directly by a developer when they need to run it.

I don't like how there is a separate build system like this. The fact that a resource does not need to be built everytime, but only when it is needed, is not a reason for it to not be built like everything else in the JDK source tree. If J2DBench is needed by developers, then the normal build system should be able to handle building that.

Now this discussion is spinning away a bit from the original PR, but I'd like to better understand what purpose the remaining demos serve, and if they are really located in the right place.

>From what I can see we have these demos:

* java2d/J2DBench
* jfc/CodePointIM
* jfc/FileChooserDemo
* jfc/Font2DTest
* jfc/J2Ddemo
* jfc/Metalworks
* jfc/Notepad
* jfc/SampleTree
* jfc/Stylepad
* jfc/SwingSet2
* jfc/TableExample
* jfc/TransparentRuler

All the jfc demos are built by the normal JDK build system. But some of them also have additional build.xml files, and J2DBench also have a separate Makefile.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3036052948

From aivanov at openjdk.org  Fri Jul  4 12:42:39 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 4 Jul 2025 12:42:39 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <Ou0gfoVOGOIyiyF36DLtRL2mPLkawx09x8R4XAd-K94=.5f78d479-b0bd-4c95-b472-c93f483b041c@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <Ou0gfoVOGOIyiyF36DLtRL2mPLkawx09x8R4XAd-K94=.5f78d479-b0bd-4c95-b472-c93f483b041c@github.com>
Message-ID: <u3U8WiW97lEeLpZz8koI_EAX1S5UPuvgF9_nTI0AUrA=.1f68cf1c-99f3-42dd-bb9e-240581706753@github.com>

On Fri, 4 Jul 2025 12:07:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > The test has to re-create its UI after testing for a L&F is complete. Such a scenario isn't supported by `PassFailJFrame` at the moment, see [JDK-8357455](https://bugs.openjdk.org/browse/JDK-8357455) and [#24439 (comment)](https://github.com/openjdk/jdk/pull/24439#discussion_r2100038079). There's no easy workaround.
> > The test doesn't receive events from `PassFailJFrame`, so the needs to be a custom UI, or the test should be run several times for different L&Fs.
> 
> So do you propose to test like what is being done in https://github.com/openjdk/jdk/pull/24439/files passing L&F argument to jtreg tag?

Yes, this is the simplest way.

Another option is to have a driver class. For example, if no arguments are passed to `main`, the test gets the list of all available or specific L&F as hard-coded now, then runs the same test with a parameter that specifies a L&F to test. The driver then captures both standard output and error streams of the process and throws an exception if the exit code from the subprocess isn't 0.

The first approach is simpler as it uses jtreg to run the test with different parameters.

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

PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3036103833

From duke at openjdk.org  Fri Jul  4 13:08:59 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 4 Jul 2025 13:08:59 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v3]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <eqz3p2m3ZmJgFo31UQgvVeMOCzOn3GBSELpzmp6CmK8=.66c61d64-1c44-42b2-9a64-e9d9ad0ed5e8@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

 - Merge branch 'openjdk:master' into jdk-8158801
 - Changes protected fields to static
 - Problem list files for Mac OS only
 - Removes passed tests from problem list
 - Changes Frame width to 300, uses protected constants for all base tests frame sizes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/fa864b2f..9c7b4c70

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

  Stats: 14219 lines in 615 files changed: 8042 ins; 3791 del; 2386 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From aivanov at openjdk.org  Fri Jul  4 13:20:47 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 4 Jul 2025 13:20:47 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <55aysCZXurqsNGOCzpY51V5H6L-KTnrTHyNyZWR0D_E=.3ef2c49b-9323-4604-8bf0-75515c7b9097@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com>
 <jTfs-ve48402p333JuIyOnJjFoKqwNaUJa45_du_zu8=.5abcab29-f372-488e-853c-014ebc14dc7d@github.com>
 <QFetdv19Jeuk2nIJ5jG8Ju6dc8fJvADjILW9P0UN9Ts=.19ac45fa-5170-4cc2-bf11-2edd690273c3@github.com>
 <LQrOMe-aKNLvLvivFzUe2HyHCjz3J2TocWEchAwoQ7E=.d64bc1ee-3f77-40a7-976c-3f88a7fb68d6@github.com>
 <ihbtQ4a1zeDU1dgZ9UNHKacuK-9HB7Yxg73_yAVBNrI=.c5e3236b-e113-4670-b03d-02bb49083736@github.com>
 <55aysCZXurqsNGOCzpY51V5H6L-KTnrTHyNyZWR0D_E=.3ef2c49b-9323-4604-8bf0-75515c7b9097@github.com>
Message-ID: <xBf5YM_yisonihPCwjVrd4Y4lLyRfu74MnM4t2bk2DU=.3d90e74d-4d60-466b-ae1d-a4659bf3425f@github.com>

On Fri, 4 Jul 2025 03:23:54 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> After your latest fix, the accelerator doesn't get painted over the menu text, but the positioning is still way off.
>> 
>> With the added column for the icon the menu width has to increase but it hasn't. Instead, the width remains the same, and you squeeze both check mark / bullet and icon to the same allocated space.
>> 
>> The position of the check mark must not change in the new layout. In old rendering code, the was 29-pixel margin between the left edge and first pixel of the check mark (at 200% scale), but now it's reduced to 23 pixels only.
>> 
>> There was 24-pixel margin between an icon and text, but now it's only 6 pixels.
>> 
>> The margin between menu text and accelerator is reduced from 12 pixels to 4.
>> 
>> The menu looks too crowded, squished. You have to properly add *a new column for the icon* with margins around it whenever a popup menu has a JCheckBoxMenuItem or JRadioButtonMenuItem with an icon.
>
> I guess the positioning with latest PR today should be ok
> 
> ![image](https://github.com/user-attachments/assets/f54247e8-6cbc-4b63-972f-90a155d5bbc1)

No, it still match the style and margins that we see in Windows File Explorer.

The latest fix doesn't change much, *the width of the menu hasn't changed*: you just move the elements around trying to fit more into the same space, which unavoidably reduces margins between elements.

The margin between the check mark / bullet and the icon should be larger, that popup menu in Windows File Explorer has 35 pixel-margin between the check mark and the icon, the latest version of the fix in this review has only 7 pixels.

The width allocated for the popup menu has to increase where both check marks / bullets and icons need to be rendered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2185359330

From aivanov at openjdk.org  Fri Jul  4 13:26:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 4 Jul 2025 13:26:45 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <xBf5YM_yisonihPCwjVrd4Y4lLyRfu74MnM4t2bk2DU=.3d90e74d-4d60-466b-ae1d-a4659bf3425f@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com>
 <jTfs-ve48402p333JuIyOnJjFoKqwNaUJa45_du_zu8=.5abcab29-f372-488e-853c-014ebc14dc7d@github.com>
 <QFetdv19Jeuk2nIJ5jG8Ju6dc8fJvADjILW9P0UN9Ts=.19ac45fa-5170-4cc2-bf11-2edd690273c3@github.com>
 <LQrOMe-aKNLvLvivFzUe2HyHCjz3J2TocWEchAwoQ7E=.d64bc1ee-3f77-40a7-976c-3f88a7fb68d6@github.com>
 <ihbtQ4a1zeDU1dgZ9UNHKacuK-9HB7Yxg73_yAVBNrI=.c5e3236b-e113-4670-b03d-02bb49083736@github.com>
 <55aysCZXurqsNGOCzpY51V5H6L-KTnrTHyNyZWR0D_E=.3ef2c49b-9323-4604-8bf0-75515c7b9097@github.com>
 <xBf5YM_yisonihPCwjVrd4Y4lLyRfu74MnM4t2bk2DU=.3d90e74d-4d60-466b-ae1d-a4659bf3425f@github.com>
Message-ID: <vMhFPgTyeyhXWZSix12Btv-2lMIyTIaC_MVhuhSZQZs=.98bc24de-0832-4e66-8229-9a8b5b873dda@github.com>

On Fri, 4 Jul 2025 13:17:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I guess the positioning with latest PR today should be ok
>> 
>> ![image](https://github.com/user-attachments/assets/f54247e8-6cbc-4b63-972f-90a155d5bbc1)
>
> No, it still doesn't match the style and margins that we see in Windows File Explorer.
> 
> The latest fix doesn't change much, *the width of the menu hasn't changed*: you just move the elements around trying to fit more into the same space, which unavoidably reduces margins between elements.
> 
> The margin between the check mark / bullet and the icon should be larger, that popup menu in Windows File Explorer has 35 pixel-margin between the check mark and the icon, the latest version of the fix in this review has only 7 pixels.
> 
> The width allocated for the popup menu has to increase where both check marks / bullets and icons need to be rendered.

Compare the screenshots of File Explorer and Swing to [own comment](https://github.com/openjdk/jdk/pull/23324#issuecomment-2705406453).

There's so much ?air? in File Explorer version of the popup menu. Yes, the location of the elements in Swing has changed since that time, but it can't match that in File Explorer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2185371866

From asemenov at openjdk.org  Fri Jul  4 13:58:38 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 4 Jul 2025 13:58:38 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
Message-ID: <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>

On Wed, 2 Jul 2025 15:37:30 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> **Issue** : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
>> 
>> **Analysis** : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
>> 
>> **Proposed Fix** : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.
>> 
>> **Testing** : Manual test case has been added to verify the fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 865:

> 863:     NSString *value = nil;
> 864: 
> 865:     if ([[self javaRole] isEqualToString:@"pagetab"]) {

??? ??????? ???? ?? ????? ?????? ??????????????:

- (NSString *)accessibilityRoleDescription

? ```src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m```


It seems it would be better to simply override:

- (NSString *)accessibilityRoleDescription

in ```src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2185445536

From psadhukhan at openjdk.org  Mon Jul  7 02:27:30 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 02:27:30 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v2]
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <nBfJrT3g9Y-UtkM6uQnQ9PRqE3MGbhfcLEeTfNpqDPo=.910035b2-10f8-4a46-bdf1-bacb483a3115@github.com>

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  L&F run as different test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25907/files
  - new: https://git.openjdk.org/jdk/pull/25907/files/8d0f9887..5283fd20

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

  Stats: 76 lines in 1 file changed: 42 ins; 22 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25907/head:pull/25907

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

From psadhukhan at openjdk.org  Mon Jul  7 02:33:39 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 02:33:39 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v2]
In-Reply-To: <nBfJrT3g9Y-UtkM6uQnQ9PRqE3MGbhfcLEeTfNpqDPo=.910035b2-10f8-4a46-bdf1-bacb483a3115@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <nBfJrT3g9Y-UtkM6uQnQ9PRqE3MGbhfcLEeTfNpqDPo=.910035b2-10f8-4a46-bdf1-bacb483a3115@github.com>
Message-ID: <stpjkIw-qC_id8wa4yEzXahf065fSXsipc4n8zsi8Wc=.bea66b46-1ebc-49c0-9779-be5d80f6fb53@github.com>

On Mon, 7 Jul 2025 02:27:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
>> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
>> 
>> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   L&F run as different test

ok..test rewritten to have L&F run as different test via jtreg tags..

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

PR Comment: https://git.openjdk.org/jdk/pull/25907#issuecomment-3043306096

From abhiscxk at openjdk.org  Mon Jul  7 03:14:46 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 03:14:46 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v2]
In-Reply-To: <nBfJrT3g9Y-UtkM6uQnQ9PRqE3MGbhfcLEeTfNpqDPo=.910035b2-10f8-4a46-bdf1-bacb483a3115@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <nBfJrT3g9Y-UtkM6uQnQ9PRqE3MGbhfcLEeTfNpqDPo=.910035b2-10f8-4a46-bdf1-bacb483a3115@github.com>
Message-ID: <xmG9Gyrf08LxRwaGsYtm57GOnshCWD-G51nz68PABsE=.01fbbb63-e765-4bd8-85f8-403e691d6c90@github.com>

On Mon, 7 Jul 2025 02:27:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
>> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
>> 
>> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   L&F run as different test

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 44:

> 42:  * @build PassFailJFrame
> 43:  * @run main/manual RightLeftOrientation motif
> 44:  */

Test can be extended for "Nimbus" L&F also as it is supported for all platforms.

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 86:

> 84: 
> 85:         The menu is divided into two halves. The upper half is oriented
> 86:         left-to-right and the lower half is oriented right-to-left.

Is it better ?

Suggestion:

        The menu is divided into two halves. The upper half is
        left-to-right oriented and the lower half is right-to-left oriented.

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 113:

> 111:         System.out.println("Test for LookAndFeel " + lafClassName);
> 112:         PassFailJFrame.builder()
> 113:                 .title("RightLeftOrientation Instructions")

Setting title explicitly is not required.

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 119:

> 117:                 .build()
> 118:                 .awaitAndCheck();
> 119:        System.out.println("Test passed for LookAndFeel " + lafClassName);

jtr file is available for each L&F testing and by default "Test Passed!" output is available. This doesn't seem to be useful.

     Test for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
     Test passed!
     Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188876818
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188877605
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188867260
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188879974

From abhiscxk at openjdk.org  Mon Jul  7 04:25:31 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 04:25:31 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v3]
In-Reply-To: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
Message-ID: <RmxKjfl293t9TSdHilEQRX8Zr8GR_JL0AAVGhS6bIc0=.5001ad32-3a9c-451d-9906-85fd169ae46d@github.com>

> **Issue** : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
> 
> **Analysis** : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
> 
> **Proposed Fix** : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.
> 
> **Testing** : Manual test case has been added to verify the fix.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Minor change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26096/files
  - new: https://git.openjdk.org/jdk/pull/26096/files/0bc63054..7d0b9379

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

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

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

From abhiscxk at openjdk.org  Mon Jul  7 04:25:31 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 04:25:31 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
Message-ID: <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>

On Fri, 4 Jul 2025 13:55:26 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add test
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 865:
> 
>> 863:     NSString *value = nil;
>> 864: 
>> 865:     if ([[self javaRole] isEqualToString:@"pagetab"]) {
> 
> ??? ??????? ???? ?? ????? ?????? ??????????????:
> 
> - (NSString *)accessibilityRoleDescription
> 
> ? ```src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m```
> 
> 
> It seems it would be better to simply override:
> 
> - (NSString *)accessibilityRoleDescription
> 
> in ```src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m```

I thought of overriding this method but the changes are very minimal.
Even if this method is overridden in `TabButtonAccessibility.m` and the value returned is `nil` then we need to either fallback to parent's class method or need to copy the entire implementation in `TabButtonAccessibility`.

So, I think this should be ok to cater the changes here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2188932862

From abaya at openjdk.org  Mon Jul  7 05:01:02 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 7 Jul 2025 05:01:02 GMT
Subject: Integrated: 8346952 : GetGraphicsStressTest.java fails: Native
 resources unavailable
In-Reply-To: <IZIhhbpiQldVRXt6FSVFRg9z_UNrsPN-xGjJNrufb8A=.0e1aefc5-e1d1-4b83-a764-72f632c18c48@github.com>
References: <IZIhhbpiQldVRXt6FSVFRg9z_UNrsPN-xGjJNrufb8A=.0e1aefc5-e1d1-4b83-a764-72f632c18c48@github.com>
Message-ID: <fzdebcv7HcVpObF76e3N-8jMyLuV1F2erHmNwjJXtLg=.e459f9b7-f1f3-4b17-82b6-9f69b33e9c55@github.com>

On Tue, 3 Jun 2025 15:32:01 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Analysis:**
> 
> We are encountering a race condition in the native code. While retrieving the screen number by calling _getScreenImOn(), the window is disposed. As a result, the AWT-Windows event loop processes the Dispose() call, which triggers UnlinkObjects().
> The race condition between the execution paths of these two native methods sometimes causes an exception
> 
> **Proposed Fix:**
> 
> While it's possible to introduce a synchronization mechanism, it would not offer any real benefit. The window will be disposed regardless, and we?ll fall back to the default screen. This behavior is already handled in WWindowPeer.java, where a workaround is in place to use the default device when getScreenImOn() returns a non-existent screen number
> 
> 
> public void updateGC() {
> 
>     int scrn = getScreenImOn();
> 
>     if (screenLog.isLoggable(PlatformLogger.Level.FINER)) {
>         log.finer("Screen number: " + scrn);
>     }
> 
>     // get current GD
>     Win32GraphicsDevice oldDev = winGraphicsConfig.getDevice();
> 
>     Win32GraphicsDevice newDev;
>     GraphicsDevice[] devs = GraphicsEnvironment
>         .getLocalGraphicsEnvironment()
>         .getScreenDevices();
> 
>     // Occasionally during device addition/removal getScreenImOn can return
>     // a non-existing screen number. Use the default device in this case.
>     if (scrn >= devs.length) {
>         newDev = (Win32GraphicsDevice) GraphicsEnvironment
>             .getLocalGraphicsEnvironment().getDefaultScreenDevice();
>     } else {
>         newDev = (Win32GraphicsDevice) devs[scrn];
>     }
> }
> 
> 
> Therefore, I propose modifying the native method getScreenImOn to return the default device if the peer is being disposed :
> 
> jint AwtWindow::_GetScreenImOn(void *param)
> {
> ...
>     jboolean destroyed = JNI_GET_DESTROYED(self);
>     if (destroyed == JNI_TRUE){
>         env->DeleteGlobalRef(self);
>         return AwtWin32GraphicsDevice::GetDefaultDeviceIndex();
>     }
> ...
> 
> 
> **Tests Summary:**
> 
>   GetGraphicsStressTest (existing test):
> 
>         Fails intermittently without the fix
> 
>         Consistently passes with the fix
> 
>   NotifyStressTest (newly added test):
> 
>          Consistently fails without the fix
> 
>          Consistently passes with the fix

This pull request has now been integrated.

Changeset: 44cff9d6
Author:    Anass Baya <abaya at openjdk.org>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44cff9d6abab5df086e89df16f8b63c48cd33c7b
Stats:     76 lines in 3 files changed: 54 ins; 14 del; 8 mod

8346952: GetGraphicsStressTest.java fails: Native resources unavailable

Reviewed-by: serb

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

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

From psadhukhan at openjdk.org  Mon Jul  7 05:05:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 05:05:01 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v3]
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <vELDqklNpaKNs54LLcavHGWXloe78R3Voockjk6eppk=.f6c37276-4fd5-43c8-9f83-01ec7e41b670@github.com>

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove title

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25907/files
  - new: https://git.openjdk.org/jdk/pull/25907/files/5283fd20..47354410

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

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

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

From psadhukhan at openjdk.org  Mon Jul  7 05:05:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 05:05:01 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v2]
In-Reply-To: <xmG9Gyrf08LxRwaGsYtm57GOnshCWD-G51nz68PABsE=.01fbbb63-e765-4bd8-85f8-403e691d6c90@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <nBfJrT3g9Y-UtkM6uQnQ9PRqE3MGbhfcLEeTfNpqDPo=.910035b2-10f8-4a46-bdf1-bacb483a3115@github.com>
 <xmG9Gyrf08LxRwaGsYtm57GOnshCWD-G51nz68PABsE=.01fbbb63-e765-4bd8-85f8-403e691d6c90@github.com>
Message-ID: <9nHLF4-WFpa8j0Rr-H12umjDUxZDw6pF9ytX2zT_luY=.78100111-af35-4b2e-aad9-0650fef24dd7@github.com>

On Mon, 7 Jul 2025 03:07:08 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   L&F run as different test
>
> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 44:
> 
>> 42:  * @build PassFailJFrame
>> 43:  * @run main/manual RightLeftOrientation motif
>> 44:  */
> 
> Test can be extended for "Nimbus" L&F also as it is supported for all platforms.

Test enhancement can be done in separate PR..even it can be extended for other platforms..but this PR only caters to the problem at hand..

> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 86:
> 
>> 84: 
>> 85:         The menu is divided into two halves. The upper half is oriented
>> 86:         left-to-right and the lower half is oriented right-to-left.
> 
> Is it better ?
> 
> Suggestion:
> 
>         The menu is divided into two halves. The upper half is
>         left-to-right oriented and the lower half is right-to-left oriented.

guess it's same..

> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 113:
> 
>> 111:         System.out.println("Test for LookAndFeel " + lafClassName);
>> 112:         PassFailJFrame.builder()
>> 113:                 .title("RightLeftOrientation Instructions")
> 
> Setting title explicitly is not required.

ok

> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 119:
> 
>> 117:                 .build()
>> 118:                 .awaitAndCheck();
>> 119:        System.out.println("Test passed for LookAndFeel " + lafClassName);
> 
> jtr file is available for each L&F testing and by default "Test Passed!" output is available. This doesn't seem to be useful.
> 
>      Test for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel
>      Test passed!
>      Test passed for LookAndFeel javax.swing.plaf.metal.MetalLookAndFeel

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188973831
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188974203
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188972789
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188974386

From abhiscxk at openjdk.org  Mon Jul  7 05:10:40 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 05:10:40 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v3]
In-Reply-To: <vELDqklNpaKNs54LLcavHGWXloe78R3Voockjk6eppk=.f6c37276-4fd5-43c8-9f83-01ec7e41b670@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <vELDqklNpaKNs54LLcavHGWXloe78R3Voockjk6eppk=.f6c37276-4fd5-43c8-9f83-01ec7e41b670@github.com>
Message-ID: <KMYLWDEU1LLkTcXmv-XE-oaPf6k9e8HVH8m2Ru3wSsI=.cb90bef2-bdb2-42d5-b10c-5aad276882ea@github.com>

On Mon, 7 Jul 2025 05:05:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
>> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
>> 
>> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove title

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 127:

> 125: 
> 126:         frame.setJMenuBar(menuBar);
> 127:         frame.pack();

Test frame title is not visible when `frame.pack` is used
Suggestion:

        frame.setSize(250, 100);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188979537

From psadhukhan at openjdk.org  Mon Jul  7 05:18:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 05:18:56 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v4]
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <DH1Qd35W6zkx2V2mRcwEA-LSVveUZAmA56yDAr8zikE=.0fe137fb-a2f1-429b-ae2a-b4841a0153b8@github.com>

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  setsize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25907/files
  - new: https://git.openjdk.org/jdk/pull/25907/files/47354410..1d62e24f

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

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

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

From psadhukhan at openjdk.org  Mon Jul  7 05:18:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 05:18:56 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v3]
In-Reply-To: <KMYLWDEU1LLkTcXmv-XE-oaPf6k9e8HVH8m2Ru3wSsI=.cb90bef2-bdb2-42d5-b10c-5aad276882ea@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <vELDqklNpaKNs54LLcavHGWXloe78R3Voockjk6eppk=.f6c37276-4fd5-43c8-9f83-01ec7e41b670@github.com>
 <KMYLWDEU1LLkTcXmv-XE-oaPf6k9e8HVH8m2Ru3wSsI=.cb90bef2-bdb2-42d5-b10c-5aad276882ea@github.com>
Message-ID: <Qe1udYwIBvgojPj0sX9KI4Wwrn-IZoIEwLeH5ZhJbmo=.b476dca6-77ec-4a04-a220-61ba86042881@github.com>

On Mon, 7 Jul 2025 05:07:51 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove title
>
> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 127:
> 
>> 125: 
>> 126:         frame.setJMenuBar(menuBar);
>> 127:         frame.pack();
> 
> Test frame title is not visible when `frame.pack` is used
> Suggestion:
> 
>         frame.setSize(250, 100);

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2188987750

From duke at openjdk.org  Mon Jul  7 05:31:52 2025
From: duke at openjdk.org (ANUPAM DEV)
Date: Mon, 7 Jul 2025 05:31:52 GMT
Subject: RFR: 8361463: Render method of javax.swing.text.AbstractDocument uses
 'currency' instead of 'concurrency'
Message-ID: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>

Hello,
This is a trivial change in the documentation of render method of AbstractDocument class.
Changed currency to concurrency

Kindly review.

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

Commit messages:
 - Changed `currency` to `concurrency` in AbstractDocument.java `render` method

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

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

From psadhukhan at openjdk.org  Mon Jul  7 05:36:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 05:36:42 GMT
Subject: RFR: 8361463: Render method of javax.swing.text.AbstractDocument
 uses 'currency' instead of 'concurrency'
In-Reply-To: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
References: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
Message-ID: <67N_jjYDnuhypzmLzvZeLNRipMFESpmjyyrkQfqYPAU=.948cffb9-c22f-4d74-9cc6-236aa8a1fe0b@github.com>

On Mon, 7 Jul 2025 05:27:11 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hello,
> This is a trivial change in the documentation of render method of AbstractDocument class.
> Changed currency to concurrency
> 
> Kindly review.

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26154#pullrequestreview-2992224232

From tr at openjdk.org  Mon Jul  7 05:44:43 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 7 Jul 2025 05:44:43 GMT
Subject: RFR: 8361463: Render method of javax.swing.text.AbstractDocument
 uses 'currency' instead of 'concurrency'
In-Reply-To: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
References: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
Message-ID: <ePTeizxVUd8JppfgkCrPU83Kz-B4odUANd0ONNg2uDI=.6a7c7061-727e-49ce-a47f-da2e94d2c225@github.com>

On Mon, 7 Jul 2025 05:27:11 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hello,
> This is a trivial change in the documentation of render method of AbstractDocument class.
> Changed currency to concurrency
> 
> Kindly review.

Marked as reviewed by tr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26154#pullrequestreview-2992242614

From abhiscxk at openjdk.org  Mon Jul  7 05:44:43 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 05:44:43 GMT
Subject: RFR: 8361463: Render method of javax.swing.text.AbstractDocument
 uses 'currency' instead of 'concurrency'
In-Reply-To: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
References: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
Message-ID: <Ddg-Y5p9HUIL-98yO_hDjUtdl7UBYpIhAJu-6vghsvI=.27bcb38e-12b2-4351-814a-b733b3a636eb@github.com>

On Mon, 7 Jul 2025 05:27:11 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hello,
> This is a trivial change in the documentation of render method of AbstractDocument class.
> Changed currency to concurrency
> 
> Kindly review.

Marked as reviewed by abhiscxk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26154#pullrequestreview-2992244164

From abhiscxk at openjdk.org  Mon Jul  7 06:02:41 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 06:02:41 GMT
Subject: [jdk25] RFR: 8359889: java/awt/MenuItem/SetLabelTest.java
 inadvertently triggers clicks on items pinned to the taskbar
In-Reply-To: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>
References: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>
Message-ID: <j47hZVPwJ8b1wCZfZoISE14qkeOSMPdEEwmdnsDplTA=.153fbeb8-716c-4a87-9068-ebcdd224fb54@github.com>

On Fri, 4 Jul 2025 09:27:33 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> This is the backport of a test stabilisation fix done by @manukumarvs and approved by @aivanov-jdk.
> 
> Issue:
> In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine.
> 
> Fix:
> Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null).

Marked as reviewed by abhiscxk (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26128#pullrequestreview-2992274103

From duke at openjdk.org  Mon Jul  7 06:06:38 2025
From: duke at openjdk.org (duke)
Date: Mon, 7 Jul 2025 06:06:38 GMT
Subject: [jdk25] RFR: 8359889: java/awt/MenuItem/SetLabelTest.java
 inadvertently triggers clicks on items pinned to the taskbar
In-Reply-To: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>
References: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>
Message-ID: <f1-WgdZT0-YOzEcUc0FYZDj_Gpih-zSUuP_TpPbpFHU=.d1a787d1-67d4-41db-85a2-54708488fe7c@github.com>

On Fri, 4 Jul 2025 09:27:33 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> This is the backport of a test stabilisation fix done by @manukumarvs and approved by @aivanov-jdk.
> 
> Issue:
> In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine.
> 
> Fix:
> Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null).

@manukumarvs 
Your change (at version 61a51569611f3285519ea1036142f114b1d3f1a6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26128#issuecomment-3043582134

From asemenov at openjdk.org  Mon Jul  7 06:11:40 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 7 Jul 2025 06:11:40 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
 <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
Message-ID: <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>

On Mon, 7 Jul 2025 04:21:13 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m line 865:
>> 
>>> 863:     NSString *value = nil;
>>> 864: 
>>> 865:     if ([[self javaRole] isEqualToString:@"pagetab"]) {
>> 
>> ??? ??????? ???? ?? ????? ?????? ??????????????:
>> 
>> - (NSString *)accessibilityRoleDescription
>> 
>> ? ```src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m```
>> 
>> 
>> It seems it would be better to simply override:
>> 
>> - (NSString *)accessibilityRoleDescription
>> 
>> in ```src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m```
>
> I thought of overriding this method but the changes are very minimal.
> Even if this method is overridden in `TabButtonAccessibility.m` and the value returned is `nil` then we need to either fallback to parent's class method or need to copy the entire implementation in `TabButtonAccessibility`.
> 
> So, I think this should be ok to cater the changes here.

Do it where it makes sense as part of the tab button implementation, rather than adding workarounds to the general implementation.

Check the [super accessibilityRoleDescription] and if it returns nil, return your implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2189060645

From abhiscxk at openjdk.org  Mon Jul  7 06:34:43 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 06:34:43 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v2]
In-Reply-To: <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
Message-ID: <Okxwz68KwRZP51syF0SSrS03wECdl6sfv7bv96zGM_4=.b1f7e5c2-1b2a-4e8c-aa81-9dec40845029@github.com>

On Tue, 1 Jul 2025 10:12:29 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: EventQueue.invokeAndWait used

Fix to dispose the frame looks good but the test needs re-factoring like expand wild imports, accessing UI components on EDT, code formatting etc.

I suggest to raise a JBS issue to address these issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/26043#issuecomment-3043636025

From psadhukhan at openjdk.org  Mon Jul  7 06:34:44 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 06:34:44 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v2]
In-Reply-To: <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
Message-ID: <81LzMLqaL6ykk302dzTdijz6hLjEWBdzawFRIc4GjXQ=.803ebac7-00e3-49ca-87c6-6fbef1451068@github.com>

On Tue, 1 Jul 2025 10:12:29 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: EventQueue.invokeAndWait used

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 54:

> 52:     }
> 53: 
> 54:     public static void main(String []s) throws InvocationTargetException, InterruptedException, AWTException{

Better to have "throws Exception" and expand wildcard imports.
Remove author tag

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 55:

> 53: 
> 54:     public static void main(String []s) throws InvocationTargetException, InterruptedException, AWTException{
> 55:         frame = new ExtraButtonDrag();

please use robot.waitForIdle before robot.delay after frame is set visible..

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 127:

> 125:             }
> 126:         }
> 127:         finally {

move finally to previous line as per coding guideline.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2189079934
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2189086627
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2189081285

From psadhukhan at openjdk.org  Mon Jul  7 06:34:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 06:34:45 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v2]
In-Reply-To: <81LzMLqaL6ykk302dzTdijz6hLjEWBdzawFRIc4GjXQ=.803ebac7-00e3-49ca-87c6-6fbef1451068@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
 <81LzMLqaL6ykk302dzTdijz6hLjEWBdzawFRIc4GjXQ=.803ebac7-00e3-49ca-87c6-6fbef1451068@github.com>
Message-ID: <ooU2pVp2YBoERmodyF5Yd9QcUFGJxojEk5WHlxjLcEs=.a9e56445-3c32-4b48-963a-908689e4f51c@github.com>

On Mon, 7 Jul 2025 06:26:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8361067: EventQueue.invokeAndWait used
>
> test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 55:
> 
>> 53: 
>> 54:     public static void main(String []s) throws InvocationTargetException, InterruptedException, AWTException{
>> 55:         frame = new ExtraButtonDrag();
> 
> please use robot.waitForIdle before robot.delay after frame is set visible..

Call frame AWT API  within EDT as you are doing for disposeFrame

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2189090966

From psadhukhan at openjdk.org  Mon Jul  7 06:34:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 06:34:45 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v2]
In-Reply-To: <ooU2pVp2YBoERmodyF5Yd9QcUFGJxojEk5WHlxjLcEs=.a9e56445-3c32-4b48-963a-908689e4f51c@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
 <81LzMLqaL6ykk302dzTdijz6hLjEWBdzawFRIc4GjXQ=.803ebac7-00e3-49ca-87c6-6fbef1451068@github.com>
 <ooU2pVp2YBoERmodyF5Yd9QcUFGJxojEk5WHlxjLcEs=.a9e56445-3c32-4b48-963a-908689e4f51c@github.com>
Message-ID: <xRj8d0Q_2VXXbdZtmx_SgSB3tijMQSUhprB8z8XWj3U=.8a7ef03e-0a1d-49ac-ae79-4eff28faaf87@github.com>

On Mon, 7 Jul 2025 06:29:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 55:
>> 
>>> 53: 
>>> 54:     public static void main(String []s) throws InvocationTargetException, InterruptedException, AWTException{
>>> 55:         frame = new ExtraButtonDrag();
>> 
>> please use robot.waitForIdle before robot.delay after frame is set visible..
>
> Call frame AWT API  within EDT as you are doing for disposeFrame

take a look at the spacing throughout the (like between the operator etc) file since anyway you are updating the test..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2189094090

From abhiscxk at openjdk.org  Mon Jul  7 06:51:42 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 06:51:42 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
 <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
 <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>
Message-ID: <DNvqxX-AkQiCJYU3HGUh9Odm1kDYi4rw5DKshsbCRV0=.65931a07-bda4-4534-b65a-d206b9d02c72@github.com>

On Mon, 7 Jul 2025 06:08:58 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> Check the [super accessibilityRoleDescription] and if it returns nil, return your implementation.

As I mentioned earlier in the description, `accessibility role description is fetched in accessibilityRoleDescription API in CommonComponentAccessiblity.m file, the sub-role passed as a parameter is nil, returned value is RadioButton`, [super accessibilityRoleDescription] will not return `nil`.

Anyways, I don't see this method getting invoked in TabButtonAccessibility by a11y client.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2189121633

From psadhukhan at openjdk.org  Mon Jul  7 07:19:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 07:19:45 GMT
Subject: RFR: 8008222: [macosx] selectNextChangeLead is not implemented for
 Tree in Aqua LAF [v2]
In-Reply-To: <n5rfmWPxCGA_mXnHhRet8epSNGbXD4818LXkaPv45-w=.da7786a4-e259-4f2e-a227-660412250d8d@github.com>
References: <c5QzVaRau-hKMcULFzYUpUupKUtQUzzwRthvBdgxyRs=.06b6de33-9e66-491f-bf28-d6e1a41206af@github.com>
 <n5rfmWPxCGA_mXnHhRet8epSNGbXD4818LXkaPv45-w=.da7786a4-e259-4f2e-a227-660412250d8d@github.com>
Message-ID: <GbDVI2DZjurGIb32ZW35pPhkFya6sgsBtAbYRIuiWfU=.c7e39e4a-0a84-47f5-8954-9dde8008ca4d@github.com>

On Tue, 24 Jun 2025 12:11:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY).....
>> Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them
>> so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead
>> 
>> No regression test as it can be verified through SwingSet2 demo as below..
>> 
>> With ctrl+shift+down
>> <img width="124" alt="Screenshot 2025-06-19 at 1 41 39?PM" src="https://github.com/user-attachments/assets/8baa386e-b03a-4fd2-b5e2-4ac26157e5af" />
>> 
>> another ctrl+shift+down
>> <img width="127" alt="Screenshot 2025-06-19 at 1 42 39?PM" src="https://github.com/user-attachments/assets/572a806c-4d54-4045-b92a-c1e88d403305" />
>> 
>> Now, ctrl+shift+up
>> <img width="134" alt="Screenshot 2025-06-19 at 1 44 51?PM" src="https://github.com/user-attachments/assets/6d671852-f7b7-434f-8688-6c5dd4b3cdb5" />
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test

Yes, seems to be

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

PR Comment: https://git.openjdk.org/jdk/pull/25892#issuecomment-3043756878

From psadhukhan at openjdk.org  Mon Jul  7 07:19:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 07:19:45 GMT
Subject: Withdrawn: 8008222: [macosx] selectNextChangeLead is not implemented
 for Tree in Aqua LAF
In-Reply-To: <c5QzVaRau-hKMcULFzYUpUupKUtQUzzwRthvBdgxyRs=.06b6de33-9e66-491f-bf28-d6e1a41206af@github.com>
References: <c5QzVaRau-hKMcULFzYUpUupKUtQUzzwRthvBdgxyRs=.06b6de33-9e66-491f-bf28-d6e1a41206af@github.com>
Message-ID: <2j8Xl-DvYvzEXNF91iVFpCJ46mHDkEz7Ns9XP8E73ek=.29bd5e05-54bc-4838-9da5-022ef76c5287@github.com>

On Thu, 19 Jun 2025 07:59:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> There is no shortcuts for selectNextChangeLead and selectPreviousChangeLead in Aqua LAF which updates [LEAD_SELECTION_PATH_PROPERTY](https://docs.oracle.com/en/java/javase/24/docs/api/java.desktop/javax/swing/JTree.html#LEAD_SELECTION_PATH_PROPERTY).....
> Other L&F uses "ctrl DOWN/UP" to selectNextChangeLead/selectPreviousChangeLead but same shortcut cannot be used in mac as "ctrl DOWN" shortcut is used to display the window of current active application while "ctrl UP" is used to display all windows of all applications which allows to switch between them
> so used CTRL+SHIFT+DOWN for the selectNextChangeLead CTRL+SHIFT+UP for selectPreviousChangeLead
> 
> No regression test as it can be verified through SwingSet2 demo as below..
> 
> With ctrl+shift+down
> <img width="124" alt="Screenshot 2025-06-19 at 1 41 39?PM" src="https://github.com/user-attachments/assets/8baa386e-b03a-4fd2-b5e2-4ac26157e5af" />
> 
> another ctrl+shift+down
> <img width="127" alt="Screenshot 2025-06-19 at 1 42 39?PM" src="https://github.com/user-attachments/assets/572a806c-4d54-4045-b92a-c1e88d403305" />
> 
> Now, ctrl+shift+up
> <img width="134" alt="Screenshot 2025-06-19 at 1 44 51?PM" src="https://github.com/user-attachments/assets/6d671852-f7b7-434f-8688-6c5dd4b3cdb5" />

This pull request has been closed without being integrated.

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

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

From davidalayachew at gmail.com  Mon Jul  7 07:30:24 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 7 Jul 2025 03:30:24 -0400
Subject: [External] : Re: Windows Magnifier does not work with my Swing
 applications
In-Reply-To: <IA3PR10MB8757CF0028014132C60F5EDACF4FA@IA3PR10MB8757.namprd10.prod.outlook.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
 <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
 <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>
 <SJ2PR10MB7059510B85F8249E1AD58E91CFFD2@SJ2PR10MB7059.namprd10.prod.outlook.com>
 <CAA9v-_OGuk9UAP2xN5pi+TaZXM55patErtyW38jHX5frWG2NbQ@mail.gmail.com>
 <CAA9v-_NBzWGLCm9L7bmysHWMiuBamt_hRMNMqcYZAEe_=i2ycQ@mail.gmail.com>
 <SJ2PR10MB7059FC939F6FAC7F96C6835BCF90A@SJ2PR10MB7059.namprd10.prod.outlook.com>
 <CAA9v-_PuV+u_Yd-hEVfZ5rLk94=Yzd1yMADUEuoGTrGTmDyKrw@mail.gmail.com>
 <IA3PR10MB8757CF0028014132C60F5EDACF4FA@IA3PR10MB8757.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_P=1OV55r-NSHym2mVg6f=VZuVbYU5q7zc7bb4PCk-4xg@mail.gmail.com>

Understood. Thanks for taking a look at this. Here's hoping we get this
accessibility feature someday. But for now, this is progress enough. Thanks
again for looking into it.

On Mon, Jul 7, 2025, 3:04?AM Abhishek Kumar <abhishek.cx.kumar at oracle.com>
wrote:

> Hello David,
>
>
>
> I looked into the issue and tried to extend the support for Windows
> Magnifier for Swing application but the solution didn?t work out. I have
> captured my analysis in JBS for reference.
>
>
>
> It looks like this needs further experimentation but, I can?t commit any
> timeline for now.
>
>
>
> Thank you for your patience.
>
>
>
> Regards,
>
> Abhishek
>
>
>
> *From: *David Alayachew <davidalayachew at gmail.com>
> *Date: *Thursday, 15 May 2025 at 2:15?PM
> *To: *Abhishek Kumar <abhishek.cx.kumar at oracle.com>
> *Cc: *Philip Race <philip.race at oracle.com>, Ajit Ghaisas <
> ajit.ghaisas at oracle.com>, client-libs-dev at openjdk.org <
> client-libs-dev at openjdk.org>
> *Subject: *Re: [External] : Re: Windows Magnifier does not work with my
> Swing applications
>
> Understood. Ty vm.
>
>
>
> On Thu, May 15, 2025, 1:19?AM Abhishek Kumar <abhishek.cx.kumar at oracle.com>
> wrote:
>
> Hello David,
>
>
>
> I didn?t get enough time to investigate it further due to other priority
> work. But I will try to look into this issue ASAP.
>
>
>
> Regards,
>
> Abhishek
>
>
>
> *From: *David Alayachew <davidalayachew at gmail.com>
> *Date: *Thursday, 15 May 2025 at 8:32?AM
> *To: *Abhishek Kumar <abhishek.cx.kumar at oracle.com>
> *Cc: *Philip Race <philip.race at oracle.com>, Ajit Ghaisas <
> ajit.ghaisas at oracle.com>, client-libs-dev at openjdk.org <
> client-libs-dev at openjdk.org>
> *Subject: *Re: [External] : Re: Windows Magnifier does not work with my
> Swing applications
>
> Hey, any updates on this? I understand if not, but accessibility in Swing
> is important to me, even more so for the abovementioned reasons.
>
>
>
> On Tue, Feb 11, 2025 at 5:52?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> And thank you.
>
>
>
> On Tue, Feb 11, 2025, 12:50?AM Abhishek Kumar <
> abhishek.cx.kumar at oracle.com> wrote:
>
> Hello David,
>
>
>
> Yeah, I will evaluate if existing JDK implementation can be extended to
> work with Windows Magnifier. I didn?t get enough time to look into this
> issue due to other issues but this is on my to-do list. I will update my
> findings on JBS after my analysis.
>
>
>
> Thank you for your patience.
>
>
>
> Regards,
>
> Abhishek
>
>
>
> *From: *David Alayachew <davidalayachew at gmail.com>
> *Date: *Tuesday, 11 February 2025 at 4:39?AM
> *To: *Philip Race <philip.race at oracle.com>
> *Cc: *Abhishek Kumar <abhishek.cx.kumar at oracle.com>,
> client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
> *Subject: *[External] : Re: Windows Magnifier does not work with my Swing
> applications
>
> Ok, ty vm. Hey Abhishek, any updates?
>
>
>
> On Mon, Feb 10, 2025, 5:50?PM Philip Race <philip.race at oracle.com> wrote:
>
> I think I asked Abhishek to take a look.
>
> -phil.
>
> On 2/10/25 2:41 PM, David Alayachew wrote:
>
> Poke.
>
> Any new info?
>
>
>
> On Fri, Jan 17, 2025, 8:05?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Hello Phil,
>
> Did you get any more info about this issue?
>
>
>
> On Tue, Dec 17, 2024, 11:58?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Thanks Phil.
>
>
>
> Yeah, I am A-OK as long as this something that is looked into and the JBS
> Bug Report is updated with the findings. If this isn't too bad, this would
> be a solid inclusion. But if it's not worth the effort, I just want the JBS
> to be updated, and then I can put that as an answer for my StackOverflow
> post.
>
>
>
> Thanks again for taking a look into this.
>
>
>
> On Tue, Dec 17, 2024 at 11:56?AM Philip Race <philip.race at oracle.com>
> wrote:
>
> Perhaps .. if it is an easy fix but I do not know the specifics and the
> evaluator of that bug wrote
> "the magnifier cannot receive PropertyChangeEvents from Swing. This is a
> limitation in the Window magnifier.
> The Windows magnifier could be modified by Microsoft to receive such
> events but the work would need to be done by Microsoft."
>
> then went on to add that other magnifiers do work ..
>
> I also don't know how tied in this would be to implementing support for
> the Windows Accessibility API.
>
> Swing apps today use something called JavaAccessBridge and there are
> screen readers out there that support it.
>
> It would be good to have another look at this specific issue, but I can't
> make any promises.
>
> -phil.
>
> On 12/15/24 1:04 PM, David Alayachew wrote:
>
> Hello Client Libs Dev Team,
>
>
>
> My eyesite has started to deteriorate significantly, so I have been using
> the built-in Accessibility tool called Windows (Screen) Magnifier
> (available since Windows XP at least). It zooms in and out of the screen by
> pressing the Windows Key and (+) or (-).
>
>
>
> This works great because, as I type stuff, the magnifier will follow my
> text, so that I don't have to keep manually moving the magnifier whenever
> what I type inevitably ends up off-screen (off-view?).
>
>
>
> This feature works great for basically every other application I have,
> except my Swing apps. I make a lot of Swing apps, and I use a bunch too.
> And this Magnifier feature that follows text does not work for any of the
> ones I have tried.
>
>
>
> This feature does work on basically every other application I have. To
> name a few.
>
>
>
> * Notepad++
>
> * WordPad
>
> * Firefox
>
> * Git Bash
>
>
>
> Here is a Bug Report referring to this problem.
>
>
>
> https://bugs.openjdk.org/browse/JDK-5079680
>
>
>
> The resolution was listed as "Future Project". Any chance that the future
> can be now?
>
>
>
> I know that Swing is largely in maintenance mode, but if this were to get
> added, practically ALL Swing apps would receive a significant boost in
> accessibility. I think that's worth making some significant changes for.
>
>
>
> Finally, here is a StackOverflow post I made discussing the same subject.
>
>
>
> https://stackoverflow.com/questions/79281778
> <https://urldefense.com/v3/__https:/stackoverflow.com/questions/79281778__;!!ACWV5N9M2RV99hQ!Ly4-UF3NKnfHKegv0u1A73-bJexJCRENPe2tHIfIZbS-UVOiAyGFuQ5ftsZLZ3nYii9HnobMtSSE1q01jU3NB22v20jnRIk$>
>
>
>
> Thank you for your time.
>
> David Alayachew
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250707/00d5ae5c/attachment-0001.htm>

From asemenov at openjdk.org  Mon Jul  7 07:37:45 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 7 Jul 2025 07:37:45 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <DNvqxX-AkQiCJYU3HGUh9Odm1kDYi4rw5DKshsbCRV0=.65931a07-bda4-4534-b65a-d206b9d02c72@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
 <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
 <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>
 <DNvqxX-AkQiCJYU3HGUh9Odm1kDYi4rw5DKshsbCRV0=.65931a07-bda4-4534-b65a-d206b9d02c72@github.com>
Message-ID: <9Gpzi9EC2qKmhM7NPkpzBvD7DnL2b9ou5AgXOI1JB4o=.4420fad2-f732-4f37-a33c-4cae501242c1@github.com>

On Mon, 7 Jul 2025 06:49:12 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Do it where it makes sense as part of the tab button implementation, rather than adding workarounds to the general implementation.
>> 
>> Check the [super accessibilityRoleDescription] and if it returns nil, return your implementation.
>
>> Check the [super accessibilityRoleDescription] and if it returns nil, return your implementation.
> 
> As I mentioned earlier in the description, `accessibility role description is fetched in accessibilityRoleDescription API in CommonComponentAccessiblity.m file, the sub-role passed as a parameter is nil, returned value is RadioButton`, [super accessibilityRoleDescription] will not return `nil`.
> 
> Anyways, I don't see this method getting invoked in TabButtonAccessibility by a11y client.

Try to debug and investigate why [TabbuttonAccessibility accessibilityRoleDescription] is not being called. If you have already attempted to override it with the changes you need.

The logic of creating tabs in TabGroupAccessibility indicates that such an override should work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2189231475

From duke at openjdk.org  Mon Jul  7 07:54:43 2025
From: duke at openjdk.org (duke)
Date: Mon, 7 Jul 2025 07:54:43 GMT
Subject: RFR: 8361463: Render method of javax.swing.text.AbstractDocument
 uses 'currency' instead of 'concurrency'
In-Reply-To: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
References: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
Message-ID: <u8oMpJaw2eZ4HKL7OzjqgF68E1ikhH8k2lgAnQ0AoVQ=.2f7c471e-d1c1-414e-a237-4d7c9f659983@github.com>

On Mon, 7 Jul 2025 05:27:11 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hello,
> This is a trivial change in the documentation of render method of AbstractDocument class.
> Changed currency to concurrency
> 
> Kindly review.

@anupamdev20 
Your change (at version 8a0677a96671b7cfee19705e235c09881ae81863) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26154#issuecomment-3043856295

From duke at openjdk.org  Mon Jul  7 10:33:49 2025
From: duke at openjdk.org (Ravi-Patel8)
Date: Mon, 7 Jul 2025 10:33:49 GMT
Subject: RFR: 8361484: Remove duplicate font filename mappings in
 fontconfig.properties for AIX
Message-ID: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>

Bug Ref: https://bugs.openjdk.org/browse/JDK-8361484


The following keys are removed:

`filename.-monotype-timesnewromanwt-medium-r-normal---%d-75-75--*-gb2312.1980-0=/usr/lpp/X11/lib/X11/fonts/TrueType/tnrwt_s.ttf`

`filename.-monotype-wt_serif_sc-medium-r-normal---%d-75-75--*-iso10646-1=/usr/lpp/X11/lib/X11/fonts/TrueType/wt__s__b.ttf`

Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>

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

Commit messages:
 - Duplicate keys removed in src/java.desktop/aix/data/fontconfig/fontconfig.properties

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

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

From serb at openjdk.org  Mon Jul  7 10:33:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 7 Jul 2025 10:33:49 GMT
Subject: RFR: 8361484: Remove duplicate font filename mappings in
 fontconfig.properties for AIX
In-Reply-To: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
References: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
Message-ID: <KI9su_JwwYBAUZjJP7D9xJ36P6OxSI6Av8vrmMnM_AE=.9e0266f7-5669-4aa7-a21d-c116f0006b37@github.com>

On Mon, 16 Jun 2025 09:30:15 GMT, Ravi-Patel8 <duke at openjdk.org> wrote:

> Bug Ref: https://bugs.openjdk.org/browse/JDK-8361484
> 
> 
> The following keys are removed:
> 
> `filename.-monotype-timesnewromanwt-medium-r-normal---%d-75-75--*-gb2312.1980-0=/usr/lpp/X11/lib/X11/fonts/TrueType/tnrwt_s.ttf`
> 
> `filename.-monotype-wt_serif_sc-medium-r-normal---%d-75-75--*-iso10646-1=/usr/lpp/X11/lib/X11/fonts/TrueType/wt__s__b.ttf`
> 
> Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>

Marked as reviewed by serb (Reviewer).

Note that you need the bugID to resolve the jcheck warnings.

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

PR Review: https://git.openjdk.org/jdk/pull/25823#pullrequestreview-2951767800
Changes requested by serb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25823#pullrequestreview-2952040406

From azvegint at openjdk.org  Mon Jul  7 10:33:49 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 7 Jul 2025 10:33:49 GMT
Subject: RFR: 8361484: Remove duplicate font filename mappings in
 fontconfig.properties for AIX
In-Reply-To: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
References: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
Message-ID: <lXo4SB5ZujD9fbm_69Kb8RPfCBo3u9EydY7YF9ncELM=.16951452-1884-418d-9750-d9152906a8a5@github.com>

On Mon, 16 Jun 2025 09:30:15 GMT, Ravi-Patel8 <duke at openjdk.org> wrote:

> Bug Ref: https://bugs.openjdk.org/browse/JDK-8361484
> 
> 
> The following keys are removed:
> 
> `filename.-monotype-timesnewromanwt-medium-r-normal---%d-75-75--*-gb2312.1980-0=/usr/lpp/X11/lib/X11/fonts/TrueType/tnrwt_s.ttf`
> 
> `filename.-monotype-wt_serif_sc-medium-r-normal---%d-75-75--*-iso10646-1=/usr/lpp/X11/lib/X11/fonts/TrueType/wt__s__b.ttf`
> 
> Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25823#pullrequestreview-2971347182

From duke at openjdk.org  Mon Jul  7 10:33:50 2025
From: duke at openjdk.org (Ravi-Patel8)
Date: Mon, 7 Jul 2025 10:33:50 GMT
Subject: RFR: 8361484: Remove duplicate font filename mappings in
 fontconfig.properties for AIX
In-Reply-To: <KI9su_JwwYBAUZjJP7D9xJ36P6OxSI6Av8vrmMnM_AE=.9e0266f7-5669-4aa7-a21d-c116f0006b37@github.com>
References: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
 <KI9su_JwwYBAUZjJP7D9xJ36P6OxSI6Av8vrmMnM_AE=.9e0266f7-5669-4aa7-a21d-c116f0006b37@github.com>
Message-ID: <mqXAUwszghGobO8tRUOLsmyjbSpWiDIenl3los6G0KU=.4ce0a3c1-f569-4c0a-bfe4-aa2903924981@github.com>

On Tue, 24 Jun 2025 03:08:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Note that you need the bugID to resolve the jcheck warnings.

Thank you @mrserb, We?ve reported the bug, and it is available at: https://bugs.openjdk.org/browse/JDK-8361484

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

PR Comment: https://git.openjdk.org/jdk/pull/25823#issuecomment-3044354798

From aivanov at openjdk.org  Mon Jul  7 12:18:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 7 Jul 2025 12:18:45 GMT
Subject: RFR: 8361463: Render method of javax.swing.text.AbstractDocument
 uses 'currency' instead of 'concurrency'
In-Reply-To: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
References: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
Message-ID: <En_7_jwq0C5XhMoHfCAAaVs2LjddNEfo3vwbyZwNSm8=.bce7c8ce-5083-4ad4-9989-c2a7ce80a2ce@github.com>

On Mon, 7 Jul 2025 05:27:11 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hello,
> This is a trivial change in the documentation of render method of AbstractDocument class.
> Changed currency to concurrency
> 
> Kindly review.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26154#pullrequestreview-2993563494

From duke at openjdk.org  Mon Jul  7 12:18:45 2025
From: duke at openjdk.org (ANUPAM DEV)
Date: Mon, 7 Jul 2025 12:18:45 GMT
Subject: Integrated: 8361463: Render method of
 javax.swing.text.AbstractDocument uses 'currency' instead of 'concurrency'
In-Reply-To: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
References: <F2l1G-iPikugmCOCQ3VuoADDSy8I8zdh2a2jys-5BKw=.8c720a85-6b79-42a1-9770-c0f3c7598a5e@github.com>
Message-ID: <dR8aGvUse6B5BYc5pnMLm4L7htF4qtht2Adzg6PrjNA=.86afa74a-0443-4e6c-a1b6-a28728c2b1e7@github.com>

On Mon, 7 Jul 2025 05:27:11 GMT, ANUPAM DEV <duke at openjdk.org> wrote:

> Hello,
> This is a trivial change in the documentation of render method of AbstractDocument class.
> Changed currency to concurrency
> 
> Kindly review.

This pull request has now been integrated.

Changeset: 7c13a2cd
Author:    ANUPAM DEV <anupam.dev at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c13a2cd9aa5ec9da00084de2388abc189e2f4ef
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8361463: Render method of javax.swing.text.AbstractDocument uses 'currency' instead of 'concurrency'

Reviewed-by: psadhukhan, tr, abhiscxk, aivanov

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

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

From aturbanov at openjdk.org  Mon Jul  7 12:23:41 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 7 Jul 2025 12:23:41 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <7_E9lw5GWsglpDpKuOSrzGfg-TWZl5sJkwLoZOr9Ieg=.13505891-52f1-4eef-8a6d-8e45dbbcd08b@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
 <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
 <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>
 <BrAi6AEmVtlbCx37n70y4EuMZTXPgmQeox3h7rV5MdU=.a5166f6f-4455-4c60-8f2b-7b3721f5bbe1@github.com>
 <Cn3HZ3h1_q92LZiyEuioSfYl9dINZCbpu82JRqABtbo=.abb78b6c-bffd-4f97-8986-fffd4281ddd0@github.com>
 <YDBfmXXO0wJyQq4ifNA0YoQiUcECNgSbLiO5bbBXxec=.a1b110ed-08da-4ca3-aeb4-9f17c3fcaeb2@github.com>
 <DF8ukEr0pPYhRM8K5XbNHoQ1UBhMRzZcYuJn22HLfNg=.d9d22b75-f7e8-4489-8d84-37cc49adc8c0@github.com>
 <7_E9lw5GWsglpDpKuOSrzGfg-TWZl5sJkwLoZOr9Ieg=.13505891-52f1-4eef-8a6d-8e45dbbcd08b@github.com>
Message-ID: <930V40UNHWJQDBomDzm7rxtuhUVZFD3kc4gsY8KwFDI=.e69c1bbe-7f94-463f-8633-b62b4910791b@github.com>

On Tue, 20 May 2025 02:00:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Yet there could be a logical error anyway? `addInvalidComponent` uses identity comparison when adding a component but `removeInvalidComponent` relies on `equals` method to remove a component.
>> 
>> If a component overrides `equals`, it could lead to unpredictable behaviour: a wrong component could be removed.
>
> Then it's better to use "==" in all cases, what do you think?

Filled [JDK-8361493](https://bugs.openjdk.org/browse/)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2189912212

From aivanov at openjdk.org  Mon Jul  7 12:40:41 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 7 Jul 2025 12:40:41 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v4]
In-Reply-To: <DH1Qd35W6zkx2V2mRcwEA-LSVveUZAmA56yDAr8zikE=.0fe137fb-a2f1-429b-ae2a-b4841a0153b8@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <DH1Qd35W6zkx2V2mRcwEA-LSVveUZAmA56yDAr8zikE=.0fe137fb-a2f1-429b-ae2a-b4841a0153b8@github.com>
Message-ID: <lqofOn380WQon2F3wDtkUyDIb8lLjKBDOZBPLvjDIsA=.3dbcc8ff-8647-4da9-ab0b-973a124c115b@github.com>

On Mon, 7 Jul 2025 05:18:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
>> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
>> 
>> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   setsize

Looks good now, although I haven't run the test now.

There's a small nit around formatting to make the test code easier to read.

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 111:

> 109:             }
> 110:         });
> 111:         System.out.println("Test for LookAndFeel " + lafClassName);

Suggestion:

        if (args.length < 1) {
            throw new IllegalArgumentException("Look-and-Feel keyword is required");
        }

        final String lafClassName;
        switch (args[0]) {
            case "metal" -> lafClassName = UIManager.getCrossPlatformLookAndFeelClassName();
            case "motif" -> lafClassName = "com.sun.java.swing.plaf.motif.MotifLookAndFeel";
            case "windows" -> lafClassName = "com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
            default -> throw new IllegalArgumentException(
                           "Unsupported Look-and-Feel keyword for this test: " + args[0]);
        }

        SwingUtilities.invokeAndWait(() -> {
            try {
                UIManager.setLookAndFeel(lafClassName);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        });

        System.out.println("Test for LookAndFeel " + lafClassName);

Add some blank lines to split the long stretch of code into smaller logical blocks, which is easier to read.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25907#pullrequestreview-2993659269
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2189954518

From aivanov at openjdk.org  Mon Jul  7 12:46:44 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 7 Jul 2025 12:46:44 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <930V40UNHWJQDBomDzm7rxtuhUVZFD3kc4gsY8KwFDI=.e69c1bbe-7f94-463f-8633-b62b4910791b@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
 <hJ4PgOPmUJ1My31QgqDK7GyuPrWJMaOAROtlck4Qm3s=.180f2862-9ac7-4738-9383-c3346cc715d6@github.com>
 <55SDjO2Fj4yDEsB7Zbe3YacApuZZ5C-8x8VRO8aREJs=.3e97052f-7bd7-4dc2-83b2-4f4ecbe3bc47@github.com>
 <BrAi6AEmVtlbCx37n70y4EuMZTXPgmQeox3h7rV5MdU=.a5166f6f-4455-4c60-8f2b-7b3721f5bbe1@github.com>
 <Cn3HZ3h1_q92LZiyEuioSfYl9dINZCbpu82JRqABtbo=.abb78b6c-bffd-4f97-8986-fffd4281ddd0@github.com>
 <YDBfmXXO0wJyQq4ifNA0YoQiUcECNgSbLiO5bbBXxec=.a1b110ed-08da-4ca3-aeb4-9f17c3fcaeb2@github.com>
 <DF8ukEr0pPYhRM8K5XbNHoQ1UBhMRzZcYuJn22HLfNg=.d9d22b75-f7e8-4489-8d84-37cc49adc8c0@github.com>
 <7_E9lw5GWsglpDpKuOSrzGfg-TWZl5sJkwLoZOr9Ieg=.13505891-52f1-4eef-8a6d-8e45dbbcd08b@github.com>
 <930V40UNHWJQDBomDzm7rxtuhUVZFD3kc4gsY8KwFDI=.e69c1bbe-7f94-463f-8633-b62b4910791b@github.com>
Message-ID: <ShGS89HJZASW_9NhQSreCxtRXsnPkNB8tVEaQb3X5bk=.e3f2a984-ff3b-4a47-adaf-04fac1b67bea@github.com>

On Mon, 7 Jul 2025 12:21:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Then it's better to use "==" in all cases, what do you think?
>
> Filled [JDK-8361493](https://bugs.openjdk.org/browse/JDK-8361493)

Thank you, Andrey.

P.S. The link is broken, it doesn't lead to the JBS issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24845#discussion_r2189970911

From aivanov at openjdk.org  Mon Jul  7 12:47:40 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 7 Jul 2025 12:47:40 GMT
Subject: [jdk25] RFR: 8359889: java/awt/MenuItem/SetLabelTest.java
 inadvertently triggers clicks on items pinned to the taskbar
In-Reply-To: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>
References: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>
Message-ID: <cJIV-y7ikDJsg_wetfbrynJegfI0p8PZ2JyYqaCFImk=.ce93b4db-5e6d-4979-8e0f-3d3d6e3dc085@github.com>

On Fri, 4 Jul 2025 09:27:33 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> This is the backport of a test stabilisation fix done by @manukumarvs and approved by @aivanov-jdk.
> 
> Issue:
> In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine.
> 
> Fix:
> Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null).

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26128#pullrequestreview-2993691118

From mvs at openjdk.org  Mon Jul  7 13:17:48 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 7 Jul 2025 13:17:48 GMT
Subject: [jdk25] Integrated: 8359889: java/awt/MenuItem/SetLabelTest.java
 inadvertently triggers clicks on items pinned to the taskbar
In-Reply-To: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>
References: <44VUVBoZKIrPi1uUCvRXP4ByeG1go2qMk81kJ7iJ5-4=.2b0a2514-15ee-48a3-be94-16b9ffc2ea3d@github.com>
Message-ID: <fFadQH19fdEBjKj7y8qKcUWTz3ooYzPTymbYhGK_r6M=.5f97cb4b-97ca-42f6-94e5-afa988f172ba@github.com>

On Fri, 4 Jul 2025 09:27:33 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> This is the backport of a test stabilisation fix done by @manukumarvs and approved by @aivanov-jdk.
> 
> Issue:
> In Windows, java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar. This may open some other UI item and may interfere further testing on that machine.
> 
> Fix:
> Move the test UI to the centre of the screen by calling frame.setLocationRelativeTo(null).

This pull request has now been integrated.

Changeset: 9a73987f
Author:    Manukumar V S <mvs at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a73987f9b90af97bd2953eea0336565769dbcb7
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8359889: java/awt/MenuItem/SetLabelTest.java inadvertently triggers clicks on items pinned to the taskbar

Reviewed-by: abhiscxk, aivanov
Backport-of: b7fcd0b2351cee8d3d18abaf0bf5905d20c9d46c

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

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

From psadhukhan at openjdk.org  Mon Jul  7 14:02:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 14:02:11 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v5]
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <8_XsR2Zot42z-TMNxTWgqngtQDsp5BbrpSRZlH6ZX8Y=.63a3d08a-2ca3-4de8-8a83-3b014c7f7d4a@github.com>

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25907/files
  - new: https://git.openjdk.org/jdk/pull/25907/files/1d62e24f..081fad5e

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

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

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

From aivanov at openjdk.org  Mon Jul  7 14:56:41 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 7 Jul 2025 14:56:41 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v5]
In-Reply-To: <8_XsR2Zot42z-TMNxTWgqngtQDsp5BbrpSRZlH6ZX8Y=.63a3d08a-2ca3-4de8-8a83-3b014c7f7d4a@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <8_XsR2Zot42z-TMNxTWgqngtQDsp5BbrpSRZlH6ZX8Y=.63a3d08a-2ca3-4de8-8a83-3b014c7f7d4a@github.com>
Message-ID: <DrgpFXsZWv7H1R8j7DxUb7y-rFgzfQwPWbStfPKhMxo=.2df5075f-380d-4524-ac49-66d5218b4460@github.com>

On Mon, 7 Jul 2025 14:02:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
>> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
>> 
>> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatting

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 74:

> 72: import javax.swing.KeyStroke;
> 73: import javax.swing.LookAndFeel;
> 74: import javax.swing.SwingConstants;

Suggestion:

import javax.swing.KeyStroke;
import javax.swing.SwingConstants;

`LookAndFeel` is unused now.

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 80:

> 78: public class RightLeftOrientation {
> 79: 
> 80:     static volatile JFrame frame;

Not needed in the current test state.

test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 125:

> 123: 
> 124:     private static JFrame createTestUI() {
> 125:         frame = new JFrame("RightLeftOrientation");

`frame` should be a *local* variable again.

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

PR Review: https://git.openjdk.org/jdk/pull/25907#pullrequestreview-2994214963
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2190317498
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2190321712
PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2190323195

From psadhukhan at openjdk.org  Mon Jul  7 15:05:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 7 Jul 2025 15:05:06 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v6]
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <yqZsc07T6Ftz6DHVCq6YJh_9JgBRho_8zVfZ_i414K4=.6dc000a4-3985-4ebf-948e-d0b1f526d464@github.com>

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25907/files
  - new: https://git.openjdk.org/jdk/pull/25907/files/081fad5e..bd03ef81

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

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

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

From duke at openjdk.org  Mon Jul  7 15:27:58 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:27:58 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

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

 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Changes protected fields to static
 - Problem list files for Mac OS only
 - Removes passed tests from problem list
 - Changes Frame width to 300, uses protected constants for all base tests frame sizes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/9c7b4c70..6fe853a8

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

  Stats: 1819 lines in 63 files changed: 830 ins; 612 del; 377 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From abhiscxk at openjdk.org  Mon Jul  7 15:32:45 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 15:32:45 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v6]
In-Reply-To: <yqZsc07T6Ftz6DHVCq6YJh_9JgBRho_8zVfZ_i414K4=.6dc000a4-3985-4ebf-948e-d0b1f526d464@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <yqZsc07T6Ftz6DHVCq6YJh_9JgBRho_8zVfZ_i414K4=.6dc000a4-3985-4ebf-948e-d0b1f526d464@github.com>
Message-ID: <pj77Q5HweRQwPscWXKM0KxZlXU1XF8UZSiXSMDFw8YY=.918788ab-4607-4ab3-ad28-14de9e1fe9db@github.com>

On Mon, 7 Jul 2025 15:05:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
>> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
>> 
>> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unused import

Ran the test on Windows platform and it works as expected.

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

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25907#pullrequestreview-2994354175

From abhiscxk at openjdk.org  Mon Jul  7 15:32:46 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 15:32:46 GMT
Subject: RFR: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel [v2]
In-Reply-To: <9nHLF4-WFpa8j0Rr-H12umjDUxZDw6pF9ytX2zT_luY=.78100111-af35-4b2e-aad9-0650fef24dd7@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
 <nBfJrT3g9Y-UtkM6uQnQ9PRqE3MGbhfcLEeTfNpqDPo=.910035b2-10f8-4a46-bdf1-bacb483a3115@github.com>
 <xmG9Gyrf08LxRwaGsYtm57GOnshCWD-G51nz68PABsE=.01fbbb63-e765-4bd8-85f8-403e691d6c90@github.com>
 <9nHLF4-WFpa8j0Rr-H12umjDUxZDw6pF9ytX2zT_luY=.78100111-af35-4b2e-aad9-0650fef24dd7@github.com>
Message-ID: <VbsIBZWmlbTDhOkHzkCTw39GpTBckK2FbV4JAMaTY2I=.ac56cf10-4b0a-4e09-8b95-a5b3f6b18745@github.com>

On Mon, 7 Jul 2025 05:01:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenuItem/RightLeftOrientation.java line 44:
>> 
>>> 42:  * @build PassFailJFrame
>>> 43:  * @run main/manual RightLeftOrientation motif
>>> 44:  */
>> 
>> Test can be extended for "Nimbus" L&F also as it is supported for all platforms.
>
> Test enhancement can be done in separate PR..even it can be extended for other platforms..but this PR only caters to the problem at hand..

In that case, you can raise a JBS issue to extend the test for other platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25907#discussion_r2190412070

From duke at openjdk.org  Mon Jul  7 15:40:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 15:40:50 GMT
Subject: RFR: 8361188: Test
 java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X
Message-ID: <pRLwzmItSydBfbThg4hoOE_eNwBa2rnxLYB0-sEZPis=.1e90ff84-af12-4949-9151-cca0a6a9eb9a@github.com>

Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase.

Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'pr/25971' into jdk-8361188
 - Merge branch 'openjdk:master' into jdk-8361188
 - Removes test from Problem List
 - Returns false if component is null, in the case of embedded frame

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

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

From abhiscxk at openjdk.org  Mon Jul  7 15:45:44 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 7 Jul 2025 15:45:44 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character
In-Reply-To: <XeFNblE30cLkztzO4LugH6q2a7RpXkL6SWup38sWZzk=.e2b212a2-0017-4f0b-98ef-455752f8e007@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <KKjs4kAJW8kZE99lSEYpcOXyPvCxyNRfUQ6mB3fEYX0=.23a59cb6-21db-4b63-a844-96ddb1da14a1@github.com>
 <K8BRT3nS8fc0MJ6h3P1XNm_LNOwuhnxcZ-IqfiTDIxY=.94afafd8-b860-4426-9a9f-0bdf021062cc@github.com>
 <Cfrn8_ovavY9WJeSpmYju8k1I2jXg07XU-ON8DPhGZM=.39a0daf6-4150-406b-8add-e38b409318cd@github.com>
 <RTpQD-ESC1E5Gh_Q9ztd2cj7qgVri9aEyusuEzPSTps=.71b33672-0159-4699-ae7e-9c1381d18e87@github.com>
 <XeFNblE30cLkztzO4LugH6q2a7RpXkL6SWup38sWZzk=.e2b212a2-0017-4f0b-98ef-455752f8e007@github.com>
Message-ID: <ffs8vunXkpI7S2AvIXQuLI8n7gnprLgbqg-0IfehNYY=.3521aea5-2740-4daf-994d-473bcec17c1e@github.com>

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

>>> > I think the check is to ensure the passed index parameter is to verify the boundary of text length.
>>> 
>>> Yes, but the index passed to the method is `an index within the text`, so it should be from 0 to length - 1. You can take a look at the opposite case when the index is outside the range, for example at the beginning of the text and getAfterIndex:
>>> 
>>> > result = at.getAfterIndex(AccessibleText.CHARACTER, -1);
>>> > verifyResult("T", result);
>>> 
>>> Is that expectation correct or not? I think we should first decide whether this is actually a bug or not.
>> 
>> I got your point now. The spec says that `index an index within the text` and that means the value should range from 0 to length - 1. And that means, `getBeforeIndex` won't be able to fetch the last character and `getAfterIndex` won't be able to fetch the first character.
>> 
>> So, if someone wants to retrieve the first or last character, they shouldn't rely on `getAfterIndex and getBeforeIndex` method respectively, rather use `getAtIndex` method to get the first and last character with index passed as 0 and length -1 respectively.
>> 
>> Right ?
>
>> The spec says
> 
> What spec in particular?

@aivanov-jdk @azuev-java As per the discussion with @mrserb [here](https://github.com/openjdk/jdk/pull/25941#issuecomment-3003204161), it seems this is not an issue with the code. I would like to know about your opinion ?

If this is not an issue to fix, **can we update the javadoc for the APIs for better understanding** ?

Something like  `getBeforeIndex shouldn't be used to retrieve the last character or word or sentence` and similar for getAfterIndex and getAtIndex APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3045669182

From duke at openjdk.org  Mon Jul  7 17:41:22 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 17:41:22 GMT
Subject: RFR: 8361193: Test
 java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java fails on MacOS X
Message-ID: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>

Sets setOpaque for lightweight, and uses a compares colors with tolerance in MacOS X machines.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Removes test from Problem List
 - Fixes color comparison on for MacOS X

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

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

From duke at openjdk.org  Mon Jul  7 17:48:50 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 7 Jul 2025 17:48:50 GMT
Subject: RFR: 8361192: Test
 java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java fails on all platforms
Message-ID: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>

Changes heavyweight color to white, for the test to pass.

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

Depends on: https://git.openjdk.org/jdk/pull/25971

Commit messages:
 - Removes test from Problem List
 - Sets heavyweight background and foreground colors different than the back frame color

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

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

From prr at openjdk.org  Mon Jul  7 18:37:39 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 7 Jul 2025 18:37:39 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <PJbv1j82eNuroQIbMw90xxEE9lRDYzxIUVSoaPfcdAw=.00a59350-7417-4be4-b151-9111f96b10a5@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

The build.xml files are for people who use netbeans.
Very recently, I proposed deleting them, but someone from redhat stepped up to offer to maintain them.
https://mail.openjdk.org/pipermail/client-libs-dev/2025-June/029847.html

And people don't want to have to have to build JDK in order to use J2DBench, nor is there any reason for the JDK build to compile it, so I don't think you should sweat that the JDK build system doesn't build it. 
Putting it somewhere miles away in a JDK build directory, even if it can be done independently of building a JDK you are making it harder, not easier.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3046169408

From serb at openjdk.org  Mon Jul  7 18:45:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 7 Jul 2025 18:45:40 GMT
Subject: RFR: 8361484: Remove duplicate font filename mappings in
 fontconfig.properties for AIX
In-Reply-To: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
References: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
Message-ID: <nvyfSnGx5iZaKY8lFVY5g9afU-mxwEnX170UqvhSNZQ=.ceeb2f82-8fad-4bd9-91f6-dc0208c0e348@github.com>

On Mon, 16 Jun 2025 09:30:15 GMT, Ravi-Patel8 <duke at openjdk.org> wrote:

> Bug Ref: https://bugs.openjdk.org/browse/JDK-8361484
> 
> 
> The following keys are removed:
> 
> `filename.-monotype-timesnewromanwt-medium-r-normal---%d-75-75--*-gb2312.1980-0=/usr/lpp/X11/lib/X11/fonts/TrueType/tnrwt_s.ttf`
> 
> `filename.-monotype-wt_serif_sc-medium-r-normal---%d-75-75--*-iso10646-1=/usr/lpp/X11/lib/X11/fonts/TrueType/wt__s__b.ttf`
> 
> Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25823#pullrequestreview-2994953613

From serb at openjdk.org  Mon Jul  7 18:52:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 7 Jul 2025 18:52:38 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <Im7Zc77775n9MTH8M790OhWULHPLOiTZtw71_2XLDQU=.ea699367-8e8b-4caf-9e58-123e8b57c89c@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

But from another point of view, nothing prevents us from additionally building it as part of the JDK image or JDK test-image build, just to ensure it is buildable, and perhaps it would be useful to include it in the sanity test group simply to touch that code.(and other perf tests as well).
>Very recently, I proposed deleting them, but someone from redhat stepped up to offer to maintain them.
>https://mail.openjdk.org/pipermail/client-libs-dev/2025-June/029847.html
That was about demos, so we still can drop it in J2DBench.

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

PR Comment: https://git.openjdk.org/jdk/pull/26077#issuecomment-3046204241

From azvegint at openjdk.org  Mon Jul  7 19:27:49 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 7 Jul 2025 19:27:49 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
Message-ID: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>

When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.

To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.

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

Commit messages:
 - 8360647: [XWayland] [OL10] NumPad keys are not triggered

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

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

From serb at openjdk.org  Mon Jul  7 19:34:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 7 Jul 2025 19:34:48 GMT
Subject: Integrated: 8358623: Avoid unnecessary data copying in ICC_Profile
In-Reply-To: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com>
References: <1Kb8PXlv9qJg3FB4ZeNZiEezPUkScopiK-dtKT7sBw0=.141aa95a-dc23-48ee-b99e-1c59ec682b51@github.com>
Message-ID: <9MYLM0kRm8xTrZUXMEIwUhebFkqEnodvM87HGAql8UI=.5523fae0-dba9-41c8-a971-dedce9fd4440@github.com>

On Wed, 4 Jun 2025 23:39:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This PR simplifies several aspects of the ICC_Profile class:
> 
> - [Change 1](https://github.com/openjdk/jdk/pull/25650/commits/426a608b1df9e39e221d05e7374a3fecf6e6cf30):
>     The ICC_Profile.getInstance(byte[] data) method used to copy the profile header for validation. This copy appears redundant, as the original data array is used later anyway. This logic was originally introduced by [JDK-8347377](https://bugs.openjdk.org/browse/JDK-8347377).
> 
> - [Change 2](https://github.com/openjdk/jdk/pull/25650/commits/4035c8b1f7e1dcbc9941ead939218bba47b0a2fe):
>     In some places, the code retrieves the profile header using getData(icSigHead), which always creates a new array. It is now replaced with private getData(cmmProfile(), icSigHead) to avoid unnecessary copying. To clarify the purpose of the private method, I have added documentation.
> 
>  - [Change 3](https://github.com/openjdk/jdk/pull/25650/commits/96ad456593de3dd68c3ae6840fffee7bac68bc0c):
> After Change 2, static analysis tools began reporting a potential NPE when using getData(cmmProfile(), icSigHead), since it may return null. To address this, the internal implementation of getData was updated to always return a non-null value or throw an exception. The public method now catches this exception and returns null, as required by the specification. **Note**: this potential NPE is not a regression introduced by any changes, it simply became easier for tools to detect due to the simplified code.
> 
> @prrace @honkar-jdk please take a look

This pull request has now been integrated.

Changeset: ec3bb93d
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec3bb93d7901c7756d7ff4cc18e4ae9d88942f93
Stats:     133 lines in 4 files changed: 89 ins; 18 del; 26 mod

8358623: Avoid unnecessary data copying in ICC_Profile

Reviewed-by: honkar, prr

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

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

From prr at openjdk.org  Mon Jul  7 20:46:37 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 7 Jul 2025 20:46:37 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <NxQ00mxigQK027zpv1TlTt_UjTfN_Qu8ZY-C-k9AGVY=.67cdf3e2-d8ca-40a0-b7c2-3d73a60fed40@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26077#pullrequestreview-2995229610

From azvegint at openjdk.org  Mon Jul  7 21:46:12 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 7 Jul 2025 21:46:12 GMT
Subject: RFR: 8361524: [XWayland] possible JavaFX interop hang
Message-ID: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>

Callbacks in the `src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c` file normally have the following pattern:


helper->isDone = TRUE;
callbackEnd();
// return;


Failing to call `callbackEnd()` could result in a hang if another GTK loop is running (e.g., JavaFX see https://github.com/openjdk/jdk/pull/22131#issue-2660482472).

This fix corrects this flaw.

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

Commit messages:
 - 8361524: [XWayland] possible JavaFX interop hang

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

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

From prr at openjdk.org  Mon Jul  7 22:45:42 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 7 Jul 2025 22:45:42 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v12]
In-Reply-To: <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
Message-ID: <i4BPuNcD8H3kyeVPAeAPaCvsBJbdG9NxVxVrzvfC58M=.78e4c633-fe9f-44f4-aea9-18483e532b1c@github.com>

On Thu, 3 Jul 2025 05:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc change, description setting removed

I think we need to have the "whole picture" tested to make sure everything does as we expect.
It isn't so easy to tell even from looking at the source of ImageIcon.
Then spec'ed so developers know what to expect. 
When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images
Toolkit images are installed, even if they can't be used because the source isn't valid.
They are "effectively" null, but not "actually" null.
We should at least specify the null arg behaviours and try to say something about  invalid image data.
And as a result, I am now flipping to just documenting the setImage(null) NPE
The protected method loadImage probably needs to say it too.
Invalid image data, maybe we can cover that in a class level statement.
Note: I'd like to see every constructor tested with both null and invalid image data.

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3046707358

From serb at openjdk.org  Tue Jul  8 02:46:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 8 Jul 2025 02:46:38 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
Message-ID: <NRxUyAgO7AzbXo-yEU91O3KfRByG-8ftHKG5MTXpCCU=.6432281b-ce2c-4629-b620-9187adf7697f@github.com>

On Mon, 7 Jul 2025 19:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>To get the same result as XTest api when using NotifyKeyboardKeysym we should use XK_KP_Insert instead of XK_KP_0 regardless of NumLock state. Similarly for other Numpad keys.

Will Java receive the same keycodes if these events come from native code?

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

PR Comment: https://git.openjdk.org/jdk/pull/26170#issuecomment-3047173432

From psadhukhan at openjdk.org  Tue Jul  8 03:15:46 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 8 Jul 2025 03:15:46 GMT
Subject: Integrated: 8346753: Test
 javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on
 Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not
 visible in Nimbus LookAndFeel
In-Reply-To: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
References: <nntnuouuSxNobDt7ZB5spI7bi_7kPV4894AB2Yhf0q4=.f3aaa402-b4cb-469d-802c-5b674b44ebdf@github.com>
Message-ID: <19KxE-sXKwJSCBfcQMRJMVXh0fKy8Wm56Cpqfnwewk4=.731cc83b-c594-4ff7-ab47-cac1569f634e@github.com>

On Fri, 20 Jun 2025 03:09:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is RadioButtonMenuItem and CheckBoxMenuItem bullet/checkmark icon is not displayed in WindowsL&F when the test is run with NimbusL&F.
> This is because `WindowsIconFactory#VistaMenuItemCheckIcon.paintIcon` called `getLaFIcon()` which returns a empty NimbusIcon which causes no icons to be drawn. This is because the test after setting WIndows L&F of the menuitem reverts back the Windows L&F to Nimbus L&F via `UIManager.setLookAndFeel(save);` call in the test so when frame is made visible, the L&F resets back to Nimbus L&F resulting in null NimbusIcon.
> 
> Fix is made to make sure the whole frame is updated to cater to L&F change via `SwingUtilities.updateComponentTreeUI(frame);` call and keep the L&F without reverting back to original L&F..

This pull request has now been integrated.

Changeset: 5205eae6
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5205eae6ff28c4587ec4cb659ddffce84f00441b
Stats:     82 lines in 1 file changed: 46 ins; 23 del; 13 mod

8346753: Test javax/swing/JMenuItem/RightLeftOrientation/RightLeftOrientation.java fails on Windows Server 2025 x64 because the icons of RBMenuItem and CBMenuItem are not visible in Nimbus LookAndFeel

Reviewed-by: abhiscxk

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

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

From psadhukhan at openjdk.org  Tue Jul  8 03:20:35 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 8 Jul 2025 03:20:35 GMT
Subject: RFR: 6955128: Spec for
 javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate
 wording [v5]
In-Reply-To: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
References: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
Message-ID: <XNsAGPGxzliTolBRY3Pk200pTpjAV2iZHMsmh0fJM3Y=.cf2ba615-5cb2-4f26-9d44-0f84e41968d2@github.com>

> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named".

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  avoid latin

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25850/files
  - new: https://git.openjdk.org/jdk/pull/25850/files/4cd9caff..800c2d8c

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

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

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

From duke at openjdk.org  Tue Jul  8 05:27:39 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Jul 2025 05:27:39 GMT
Subject: RFR: 8361484: Remove duplicate font filename mappings in
 fontconfig.properties for AIX
In-Reply-To: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
References: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
Message-ID: <mDhXuMDffpPLhWewLBidmsplomhqEylp2VczzSbiJ0o=.7b7d2465-6eca-46b9-a501-0ad1f9da0d6a@github.com>

On Mon, 16 Jun 2025 09:30:15 GMT, Ravi-Patel8 <duke at openjdk.org> wrote:

> Bug Ref: https://bugs.openjdk.org/browse/JDK-8361484
> 
> 
> The following keys are removed:
> 
> `filename.-monotype-timesnewromanwt-medium-r-normal---%d-75-75--*-gb2312.1980-0=/usr/lpp/X11/lib/X11/fonts/TrueType/tnrwt_s.ttf`
> 
> `filename.-monotype-wt_serif_sc-medium-r-normal---%d-75-75--*-iso10646-1=/usr/lpp/X11/lib/X11/fonts/TrueType/wt__s__b.ttf`
> 
> Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>

@Ravi-Patel8 
Your change (at version b3da4104aaa8ad362cbb817ffa03528ed1b63e83) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25823#issuecomment-3047403350

From psadhukhan at openjdk.org  Tue Jul  8 06:02:41 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 8 Jul 2025 06:02:41 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v12]
In-Reply-To: <i4BPuNcD8H3kyeVPAeAPaCvsBJbdG9NxVxVrzvfC58M=.78e4c633-fe9f-44f4-aea9-18483e532b1c@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
 <i4BPuNcD8H3kyeVPAeAPaCvsBJbdG9NxVxVrzvfC58M=.78e4c633-fe9f-44f4-aea9-18483e532b1c@github.com>
Message-ID: <v90zuPcY6O_xsW3sPIyQpM7PXrvQyRxae3NygbwspuA=.47b79d5c-1461-47ff-a9c1-f107b6d415ce@github.com>

On Mon, 7 Jul 2025 22:43:21 GMT, Phil Race <prr at openjdk.org> wrote:

> I think we need to have the "whole picture" tested to make sure everything does as we expect. It isn't so easy to tell even from looking at the source of ImageIcon. Then spec'ed so developers know what to expect. When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images Toolkit images are installed, even if they can't be used because the source isn't valid. They are "effectively" null, but not "actually" null. We should at least specify the null arg behaviours and try to say something about invalid image data. And as a result, I am now flipping to just documenting the setImage(null) NPE The protected method loadImage probably needs to say it too. Invalid image data, maybe we can cover that in a class level statement. Note: I'd like to see every constructor tested with both null and invalid image data.

I tested with null image/imagedata and invalid imagedata and it seems only these constructors throw NPE (current JDK) for null image (invalid image doesnt throw any exception)

ImageIcon(image, desc)
ImageIcon(image)
ImageIcon(byte[], desc)
ImageIcon(byte[])

Current PR checks for null in ImageIcon(image) so it will not throw NPE but ImageIcon(byte[]) will still throw..
Should we handle those in separate PR and let this only be for setImage(null)?

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3047479917

From psadhukhan at openjdk.org  Tue Jul  8 06:16:31 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 8 Jul 2025 06:16:31 GMT
Subject: RFR: 8159055: ImageIcon.setImage and ImageIcon(Image) constructor
 can't handle null parameter [v13]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <FAAYQnxq5ochg9bKFTROph4pj5h7h2lCvQ6kjWt98dA=.09a1b6d7-6b67-4b7b-81c5-b27b7660e20d@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Revert ImageIcon constructor behavior

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/c263419e..f6cfd3a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=11-12

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

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

From psadhukhan at openjdk.org  Tue Jul  8 06:22:28 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 8 Jul 2025 06:22:28 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v14]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <Vpufu5rbsuJ8iHO6d09uYWxF3fhtvtljfm8cvDg_rww=.5a70a2d0-ad42-4ecb-8c09-2c3f8890227b@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  constructor test removal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/f6cfd3a1..340254ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=12-13

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

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

From abhiscxk at openjdk.org  Tue Jul  8 07:41:38 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 8 Jul 2025 07:41:38 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <9Gpzi9EC2qKmhM7NPkpzBvD7DnL2b9ou5AgXOI1JB4o=.4420fad2-f732-4f37-a33c-4cae501242c1@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
 <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
 <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>
 <DNvqxX-AkQiCJYU3HGUh9Odm1kDYi4rw5DKshsbCRV0=.65931a07-bda4-4534-b65a-d206b9d02c72@github.com>
 <9Gpzi9EC2qKmhM7NPkpzBvD7DnL2b9ou5AgXOI1JB4o=.4420fad2-f732-4f37-a33c-4cae501242c1@github.com>
Message-ID: <3Zqat_6_DwtqGjxNva7tUzaXPntvp5giE1dMrlSRwJo=.d081d6a5-a7e3-46f3-9108-f159ee08553a@github.com>

On Mon, 7 Jul 2025 07:34:52 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>>> Check the [super accessibilityRoleDescription] and if it returns nil, return your implementation.
>> 
>> As I mentioned earlier in the description, `accessibility role description is fetched in accessibilityRoleDescription API in CommonComponentAccessiblity.m file, the sub-role passed as a parameter is nil, returned value is RadioButton`, [super accessibilityRoleDescription] will not return `nil`.
>> 
>> Anyways, I don't see this method getting invoked in TabButtonAccessibility by a11y client.
>
> Try to debug and investigate why [TabbuttonAccessibility accessibilityRoleDescription] is not being called. If you have already attempted to override it with the changes you need.
> 
> The logic of creating tabs in TabGroupAccessibility indicates that such an override should work.

The accessible class created for a java role `pagetab` i.e. a tab component is `CommonComponentAccessibility`.
The parent for `pagetab` is `TabGroupAccessibility` and the object returned from `rowRolesMapForParent`  is `null` for `TabGroupAccessibility` in `getComponentAccessibilityClass` method. Since there is no entry in the `rolesMap` for the `pagetab` role, the returned class is `CommonComponentAccessibility`.
So, the `accessibilityRoleDescription` API is invoked from `CommonComponentAccessibility` and not from `TabButtonAccessibility`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2191726855

From asemenov at openjdk.org  Tue Jul  8 08:30:41 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 8 Jul 2025 08:30:41 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <3Zqat_6_DwtqGjxNva7tUzaXPntvp5giE1dMrlSRwJo=.d081d6a5-a7e3-46f3-9108-f159ee08553a@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
 <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
 <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>
 <DNvqxX-AkQiCJYU3HGUh9Odm1kDYi4rw5DKshsbCRV0=.65931a07-bda4-4534-b65a-d206b9d02c72@github.com>
 <9Gpzi9EC2qKmhM7NPkpzBvD7DnL2b9ou5AgXOI1JB4o=.4420fad2-f732-4f37-a33c-4cae501242c1@github.com>
 <3Zqat_6_DwtqGjxNva7tUzaXPntvp5giE1dMrlSRwJo=.d081d6a5-a7e3-46f3-9108-f159ee08553a@github.com>
Message-ID: <72C1WaCPTwiQ960VYIcvf_pp_42cyvQSHrQdhSmLfGU=.98079958-d0d2-435a-bbc7-e75dcf55f0d2@github.com>

On Tue, 8 Jul 2025 07:38:22 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Try to debug and investigate why [TabbuttonAccessibility accessibilityRoleDescription] is not being called. If you have already attempted to override it with the changes you need.
>> 
>> The logic of creating tabs in TabGroupAccessibility indicates that such an override should work.
>
> The accessible class created for a java role `pagetab` i.e. a tab component is `CommonComponentAccessibility`.
> The parent for `pagetab` is `TabGroupAccessibility` and the object returned from `rowRolesMapForParent`  is `null` for `TabGroupAccessibility` in `getComponentAccessibilityClass` method. Since there is no entry in the `rolesMap` for the `pagetab` role, the returned class is `CommonComponentAccessibility`.
> So, the `accessibilityRoleDescription` API is invoked from `CommonComponentAccessibility` and not from `TabButtonAccessibility`.

Thank you for the reference! However, I would like to advise you to thoroughly examine the code of TabGroupAccessibility. This is because it has its own implementations for creating child components.

Therefore, I am once again asking you to try to investigate the situation in more detail. There is a possibility that the mechanism is broken, and TabGroupAccessibility is not being created or used at all, which is incorrect.

Additionally, all objects in the hierarchy of native objects inherit from CommonComponentAccessibility in one way or another. If the accessibilityRoleDescription selector is not defined in TabGroupAccessibility, it may not be called.

I don?t have a Mac at hand right now; otherwise, I would debug this case myself and provide more detailed assistance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2191835850

From aivanov at openjdk.org  Tue Jul  8 12:58:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 8 Jul 2025 12:58:45 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v14]
In-Reply-To: <Vpufu5rbsuJ8iHO6d09uYWxF3fhtvtljfm8cvDg_rww=.5a70a2d0-ad42-4ecb-8c09-2c3f8890227b@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <Vpufu5rbsuJ8iHO6d09uYWxF3fhtvtljfm8cvDg_rww=.5a70a2d0-ad42-4ecb-8c09-2c3f8890227b@github.com>
Message-ID: <fu9Y19OZi8xW0cL2P4BmPmG0pYzDRAAZfZsg7RMb1cU=.bc2d4ab5-0f14-4b31-88f8-68c160d2c32a@github.com>

On Tue, 8 Jul 2025 06:22:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   constructor test removal

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 34:

> 32: import javax.swing.ImageIcon;
> 33: 
> 34: public class ImageIconNullImageTest {

I guess we're going to update the test later with follow-up fixes?

However, I suggest dropping `ImageIcon-` from the test class name ? the test is in `ImageIcon` folder, therefore it tests `ImageIcon`.

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

PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-2997530641
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2192450089

From azvegint at openjdk.org  Tue Jul  8 13:26:46 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 8 Jul 2025 13:26:46 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <NRxUyAgO7AzbXo-yEU91O3KfRByG-8ftHKG5MTXpCCU=.6432281b-ce2c-4629-b620-9187adf7697f@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
 <NRxUyAgO7AzbXo-yEU91O3KfRByG-8ftHKG5MTXpCCU=.6432281b-ce2c-4629-b620-9187adf7697f@github.com>
Message-ID: <NI9NB3fGYuhBfgzErIu7KfRCbiQtyPgb-v274gpr13w=.423dad50-20dc-47e2-a981-40e033595792@github.com>

On Tue, 8 Jul 2025 02:44:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Will Java receive the same keycodes if these events come from native code?

Yes, java receives the same events for both remote desktop emulated keystrokes and physical keystrokes, whether NumLock is on or off.

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

PR Comment: https://git.openjdk.org/jdk/pull/26170#issuecomment-3048959457

From aivanov at openjdk.org  Tue Jul  8 13:34:50 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 8 Jul 2025 13:34:50 GMT
Subject: RFR: 6955128: Spec for
 javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate
 wording [v5]
In-Reply-To: <XNsAGPGxzliTolBRY3Pk200pTpjAV2iZHMsmh0fJM3Y=.cf2ba615-5cb2-4f26-9d44-0f84e41968d2@github.com>
References: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
 <XNsAGPGxzliTolBRY3Pk200pTpjAV2iZHMsmh0fJM3Y=.cf2ba615-5cb2-4f26-9d44-0f84e41968d2@github.com>
Message-ID: <mx4eJVGWFLgXO8imDq9kdnCTV225PPShRqIZXBUwkDU=.ca223c5e-fcf1-4617-bbb8-df7b88245cf1@github.com>

On Tue, 8 Jul 2025 03:20:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named".
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid latin

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-2997681882

From aturbanov at openjdk.org  Tue Jul  8 13:42:40 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 8 Jul 2025 13:42:40 GMT
Subject: RFR: 8361193: Test
 java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java fails on MacOS X
In-Reply-To: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
References: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
Message-ID: <P7bJ6Dw1KtvXVSlgvLE50xzJSjBzLn1KNptTcpwIQqc=.a4323cfa-83da-4919-8921-e8747062897e@github.com>

On Mon, 7 Jul 2025 17:36:42 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Sets setOpaque for lightweight, and uses a compares colors with tolerance in MacOS X machines.

test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java line 305:

> 303:     private static boolean isAlmostEqualColor(Color color, Color refColor) {
> 304:         final int COLOR_TOLERANCE_MACOSX = 10;
> 305:         if(color.equals(refColor)){

Suggestion:

        if (color.equals(refColor)){

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26166#discussion_r2192568941

From duke at openjdk.org  Tue Jul  8 14:56:23 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 8 Jul 2025 14:56:23 GMT
Subject: RFR: 8361193: Test
 java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java fails on MacOS X [v2]
In-Reply-To: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
References: <cCwO7bZ1ziPtAJgFR_0SIyD1zSE5YTSdvoKAmR0bK30=.ef53d4c1-9081-4c79-a770-7ff1314b9fd0@github.com>
Message-ID: <6rwkBC8HkQrlGr1qf0r5zDYkrC8JhayWi8E7cEUJF4g=.cf18b27b-931e-4188-acdc-753fb33b21ee@github.com>

> Sets setOpaque for lightweight, and uses a compares colors with tolerance in MacOS X machines.

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Adds extra space after if
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26166/files
  - new: https://git.openjdk.org/jdk/pull/26166/files/f02885c6..65b39f02

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

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

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

From duke at openjdk.org  Tue Jul  8 15:28:14 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 8 Jul 2025 15:28:14 GMT
Subject: RFR: 8361191: Test
 java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java fails on MacOS X
Message-ID: <Z_B9aJ4T479Bk9GxIR4eI35FZLpqYYcLarqrHru98VU=.f1beedce-3dd2-41a5-bc5c-f2a9b4565c3a@github.com>

Fixes failed test by disabling heavyweight component in ItemListener.

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

Depends on: https://git.openjdk.org/jdk/pull/26162

Commit messages:
 - Removes test from Problem List
 - Disables frame in ItemListener

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

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

From duke at openjdk.org  Tue Jul  8 16:40:22 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 8 Jul 2025 16:40:22 GMT
Subject: RFR: 8361190: Test java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
 fails on MacOS X
Message-ID: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>

Add more timeout for the test to pass.

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

Depends on: https://git.openjdk.org/jdk/pull/26162

Commit messages:
 - Removes test from Problem List
 - Changes test timeout to 180 seconds

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

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

From aivanov at openjdk.org  Tue Jul  8 16:43:45 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 8 Jul 2025 16:43:45 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v14]
In-Reply-To: <Vpufu5rbsuJ8iHO6d09uYWxF3fhtvtljfm8cvDg_rww=.5a70a2d0-ad42-4ecb-8c09-2c3f8890227b@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <Vpufu5rbsuJ8iHO6d09uYWxF3fhtvtljfm8cvDg_rww=.5a70a2d0-ad42-4ecb-8c09-2c3f8890227b@github.com>
Message-ID: <lll8627IoIe4tqT_-LcAetYuB78kxV3EcoMqDYk2fIU=.6e30e8e1-cb97-4f2b-90ee-b0e4de06b603@github.com>

On Tue, 8 Jul 2025 06:22:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   constructor test removal

> > I think we need to have the "whole picture" tested to make sure everything does as we expect. ?\
> > When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images\
> > Toolkit images are installed, even if they can't be used because the source isn't valid. They are "effectively" null, but not "actually" null.
> 
> I tested with null image/imagedata and invalid imagedata and it seems only these constructors throw NPE (current JDK) for null image (invalid image doesnt throw any exception)

I wrote a JUnit test, it's more convenient than a jtreg test:

<details>
<summary><code>ImageIconConstructorsTest.java</code></summary>


import java.awt.Image;
import java.net.URL;

import javax.swing.ImageIcon;

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotNull;
import static org.junit.jupiter.api.Assertions.assertNull;
import static org.junit.jupiter.api.Assertions.assertThrows;

public class ImageIconConstructorsTest {
    @Test
    public void noArgs() {
        ImageIcon im = new ImageIcon();
        assertNull(im.getImage());
        assertNull(im.getDescription());
    }

    @Test
    public void stringNull() {
        ImageIcon im = new ImageIcon((String) null);
        assertNotNull(im.getImage());
        assertNull(im.getDescription());
    }

    @Test
    public void stringNullNull() {
        ImageIcon im = new ImageIcon((String) null, null);
        assertNotNull(im.getImage());
        assertNull(im.getDescription());
    }

    @Test
    public void stringNullWithDescription() {
        ImageIcon im = new ImageIcon((String) null, "Description");
        assertNotNull(im.getImage());
        assertEquals("Description", im.getDescription());
    }

    @Test
    public void byteArrayNull() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((byte[]) null));
//        ImageIcon im = new ImageIcon((byte[]) null);
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

    @Test
    public void byteArrayNullNull() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((byte[]) null, null));
//        ImageIcon im = new ImageIcon((byte[]) null, null);
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

    @Test
    public void byteArrayNullWithDescription() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((byte[]) null, "Description"));
//        ImageIcon im = new ImageIcon((byte[]) null, "Description");
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

    @Test
    public void urlNull() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((URL) null));
//        ImageIcon im = new ImageIcon((URL) null);
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

    @Test
    public void urlNullNull() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((URL) null, null));
//        ImageIcon im = new ImageIcon((URL) null, null);
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

    @Test
    public void urlNullWithDescription() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((URL) null, "Description"));
//        ImageIcon im = new ImageIcon((URL) null, "Description");
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

    @Test
    public void imageNull() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((Image) null));
//        ImageIcon im = new ImageIcon((Image) null);
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

    @Test
    public void imageNullNull() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((Image) null, null));
//        ImageIcon im = new ImageIcon((Image) null, null);
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

    @Test
    public void imageNullWithDescription() {
        assertThrows(NullPointerException.class,
                     () -> new ImageIcon((Image) null, "Description"));
//        ImageIcon im = new ImageIcon((Image) null, "Description");
//        assertNull(im.getImage());
//        assertNull(im.getDescription());
    }

}


</details>

All the test cases currently pass, and most constructors throw NPE for `null`. I haven't tested invalid arguments.

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3049620519

From prr at openjdk.org  Tue Jul  8 17:09:39 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 8 Jul 2025 17:09:39 GMT
Subject: RFR: 8358468: Enhance code consistency: java.desktop/macos
In-Reply-To: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
References: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
Message-ID: <uyVOeO4G2VheH4-acUZYGuKdabx-EvXcXvucV8uR_Hg=.7bda5119-ee75-4eac-90c0-6db579b2357b@github.com>

On Tue, 3 Jun 2025 06:38:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This PR updates the last (!!) remaining platform-specific part of the java.desktop module: macos.
> The unix/windows were previously addressed in: https://github.com/openjdk/jdk/pull/24170 , https://github.com/openjdk/jdk/pull/24941 and https://github.com/openjdk/jdk/pull/25439.
> 
> Note: Unlike on other platforms, the initial change for macOS caused the "BadSerializationTest" to fail. This test relies on internal details of the Aqua Look & Feel that were previously exposed via serialized data (and already [fails](https://bugs.openjdk.org/browse/JDK-8277817) on other platforms). Adding the final modifier to the class changes its serialVersionUID, which triggered the failure even on macOS.
> To avoid this issue, I have reverted the changes to those internal classes for now, see https://github.com/openjdk/jdk/pull/25607/commits/ff7e64b6e38a1a809d434628f304e49408135697
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff -o d.txt && grep -E '^+|^-' d.txt | grep -vE '^+++|^---'
> 
> ====================================================
> 
> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected ...

All automated tests pass.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25607#pullrequestreview-2998469065

From aivanov at openjdk.org  Tue Jul  8 17:21:43 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 8 Jul 2025 17:21:43 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v12]
In-Reply-To: <kX8OW33TLxOOfd8-jBp4RpsqbLG5H7sno2jRWAf7Lr4=.bb6932f8-5f32-44ec-ba03-081c8f6916e7@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
 <edhTglb25_ja08h79DC0LskDspzmeQXY2xFTajUKuuM=.014d3475-fbd6-4a19-b16c-ce1f43e86553@github.com>
 <kX8OW33TLxOOfd8-jBp4RpsqbLG5H7sno2jRWAf7Lr4=.bb6932f8-5f32-44ec-ba03-081c8f6916e7@github.com>
Message-ID: <iTaRzvw_Sziyg_QaMMT7t6kh6JcKJjJEm5Kih1DGZBA=.a3315de3-f4bd-43fb-964d-d2ca6988525e@github.com>

On Thu, 3 Jul 2025 09:43:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > But all-in-all I guess this description change can go in separate PR along with [above change](https://github.com/openjdk/jdk/pull/25767#discussion_r2164102520)
> 
> Have anyone submit a bug to address this deficiency? If not, I'll submit one.

I submitted [JDK-8361610](https://bugs.openjdk.org/browse/JDK-8361610): _Avoid wasted work in ImageIcon(Image) for setting description_ for updating `ImageIcon(Image)` and `ImageIcon(Image, String)` constructors.

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3049726067

From prr at openjdk.org  Tue Jul  8 19:09:03 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 8 Jul 2025 19:09:03 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v22]
In-Reply-To: <Hzte_IUFOGKwJ7th5xZPB-o8J8AqopfRzRFd3OYb0j4=.7875621f-2879-4c9b-be2a-65f3c49b91a5@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <Hzte_IUFOGKwJ7th5xZPB-o8J8AqopfRzRFd3OYb0j4=.7875621f-2879-4c9b-be2a-65f3c49b91a5@github.com>
Message-ID: <5Q1mTepuTHFssAZ8TMWprwj8On6LEpacxFIx622wFqI=.1285665f-12ea-4293-9212-e6afc13af6ac@github.com>

On Thu, 3 Jul 2025 15:55:23 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove ER from remaining modal test

src/java.desktop/share/classes/java/awt/Robot.java line 130:

> 128: 
> 129:     /**
> 130:      * Default delay for mouse {@code click} and

Default delay .. in milliseconds ..

src/java.desktop/share/classes/java/awt/Robot.java line 791:

> 789:      * A convenience method that simulates clicking a mouse button by calling {@code mousePress}
> 790:      * and {@code mouseRelease}. Invokes {@code waitForIdle} with a default {@link #DEFAULT_DELAY delay} after
> 791:      * {@code mousePress} and {@code mouseRelease} calls. For specifics on valid inputs please see

I think in a spec, we can drop "please".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2193215015
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2193196633

From prr at openjdk.org  Tue Jul  8 19:09:04 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 8 Jul 2025 19:09:04 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v15]
In-Reply-To: <rwkuHsqWQfZZAFxpylJZHZnPcWHJ1f0O2KimS7WbGxw=.2a3d404c-3000-4943-a3d9-dd619529aebc@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <xdbhtBgikqvegs36jK5HQykyZPSHJ_hhB5xDCg_dqxw=.97a8c90f-4b87-406a-b0a7-1c73722f1e26@github.com>
 <Idbkr_1O6El_xQd5NqPpe4wvCrnN7ILYcH7lK2nx-3w=.9a87e19e-f975-4820-8b89-c066c233301c@github.com>
 <rwkuHsqWQfZZAFxpylJZHZnPcWHJ1f0O2KimS7WbGxw=.2a3d404c-3000-4943-a3d9-dd619529aebc@github.com>
Message-ID: <yil7DkbhxZoYuFuqucKxEIPiYFyeyzXw58UGXWSp_kA=.bf0799f2-f2c4-4a72-b7dd-4f749a829759@github.com>

On Thu, 8 May 2025 21:24:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Robot.java line 792:
>> 
>>> 790:      * and {@code mouseRelease}. Invokes {@code waitForIdle} with a default {@link #DEFAULT_DELAY delay} after
>>> 791:      * {@code mousePress} and {@code mouseRelease} calls. For specifics on valid inputs please see
>>> 792:      * {@link java.awt.Robot#mousePress(int)}.
>> 
>> It's discussable, and I may be wrong, but I'm not a fan of documentation that is very specific about its implementation.
>> I prefer the one that was before in the `ExtendedRobot`.
>> 
>> 
>> Clicks mouse button(s) by calling {@link #mousePress(int)} and {@link #mouseRelease(int)} methods
>
> I understand the concern but in this case it is more or less explanation of what the method does. Perhaps it can be adjusted or made in to an apiNote or whatever is best.

If this method doesn't call waitForIdle there's no reason to  document here that you'll get IllegalThreadStateException if called on the EDT, and waitForIdle is the sole source of ITSE.
So since we are obliged to document the IllegalThreadStateException I don't think it does any harm to say it calls waitForIdle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2193214202

From prr at openjdk.org  Tue Jul  8 22:47:40 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 8 Jul 2025 22:47:40 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out
In-Reply-To: <BFWGBlOEf7m4RoDdO0Rs2uXo-2D6Z587HCuCelnZlAw=.ba5cafd9-4fd2-48a7-82e9-220d32c6982f@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
 <-VMpAEScXud5FONRrlVj3yi5_Q_hNt7o_jMYW0PbqoQ=.55896ef7-a9d5-4bf1-ba7f-edcac5ced621@github.com>
 <BFWGBlOEf7m4RoDdO0Rs2uXo-2D6Z587HCuCelnZlAw=.ba5cafd9-4fd2-48a7-82e9-220d32c6982f@github.com>
Message-ID: <rBo8iInUcICgsUegyOdBtD0-egPI_TqOaObF0bqaaYE=.367872c6-76ee-4a9e-a0be-1769ffbc8c67@github.com>

On Wed, 4 Jun 2025 07:42:35 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 742:
>> 
>>> 740:     private Rectangle2D getPageFormatArea(PageFormat page, double scaleX, double scaleY) {
>>> 741:         Rectangle2D.Double pageFormatArea;
>>> 742:         if (scaleX != 1 && scaleY != 1) {
>> 
>> BTW, Do we need this check as if scaleX=scaleY=1 then also no issue in doing multiplying with 1 ie scaleX and scaleY and if one of them is not 1 then we need to multiply anyway..so it seems this check is not needed?!!
>
> @prsadhuk  This is a little bit faster.  Calling the scale method with 1 does not change the affine transform, but performs unnecessary invalidation.

I think the key point is that it should be || not && 
Including in the 3 additional cases below.
I can see a case that if either is 1 then arguably scaling in the other axis is not going to help much, but it looks odd.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2193399030

From prr at openjdk.org  Tue Jul  8 22:47:42 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 8 Jul 2025 22:47:42 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out
In-Reply-To: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
Message-ID: <EnXD0-xl2uurJuu6uvgR5Lgc-GCssvLva19S8OTi1Q0=.18e687ef-a14f-4d6f-af11-d5236a232169@github.com>

On Wed, 28 May 2025 10:29:17 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> The fix for the https://bugs.openjdk.org/browse/JDK-8251928.
> 
> **Description**.
> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob.
> 
> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ):
> 1. Convert the user-space point, size, or rectangle value to device space coordinates;
> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary;
> 3. Convert the normalized value back to user space;
> 4. Draw your content using the adjusted value. 
>     
> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI.
> The 2-nd step is a drawing process in the java code (without changes).
> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI.
> The 4-th step is a drawing process in the native code (without changes).
> 
> **Tests**.
> I run all tests from javax.print package and there is no any regression.
> New test covers macOS and Linux only because we know its default DPI - 300.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 821:

> 819:                 Graphics2D delegate = new SunGraphics2D(sd, Color.black, Color.white, defaultFont);
> 820:                 if (scaleX != 1 && scaleY != 1) {
> 821:                     ((SunGraphics2D) delegate).setDevClip(0, 0,

Only SunGraphics2D itself uses this (internally).
Regardless of the scale, if the clip needs to be set, to the page dimensions, it must be set somewhere already. So this feels like it might be the wrong way to do this.
Why did you do it this way ?

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 825:

> 823:                 }
> 824:                 Graphics2D pathGraphics = new CPrinterGraphics(delegate, printerJob); // Just stores delegate into an ivar
> 825:                 Rectangle2D pageFormatArea = getPageFormatArea(page, scaleX, scaleY);

I don't think this is right. scaleX is presumably the un-rotated X resolution, but these PageFormat methods take into account the rotation.
So if you have a printer that has a resolution of x=300dpi, y=600dpi, and you go into landscape mode, then the scales will be the wrong way around.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 869:

> 867:                               new BufferedImage(
> 868:                                   (int)Math.round(pageFormat.getWidth() * scaleX),
> 869:                                   (int)Math.round(pageFormat.getHeight() * scaleY),

I don't think this is right. getXRes() is presumably the un-rotated X resolution, but these PageFormat methods take into account the rotation.
So if you have a printer that has a resolution of x=300dpi, y=600dpi, and you go into landscape mode, then the scales will be the wrong way around.

src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m line 109:

> 107:     CGContextRef cgRef = (CGContextRef)[[printLoop context] graphicsPort];
> 108: 
> 109:     //Scale to default device DPI

Not really, you are just scaling to a JDK default, not a device one.
If you want to do this properly you need to get the resolution from CUPS - like you do in the test - and pass it through to the printing resolution set up.

src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m line 117:

> 115:         double scaleX = DEFAULT_DEVICE_DPI/hRes;
> 116:         double scaleY = DEFAULT_DEVICE_DPI/vRes;
> 117:         if (scaleX != 1 && scaleY != 1) {

yet another case where you need ||

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2193555859
PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2193543602
PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2193419303
PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2193424886
PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2193424954

From serb at openjdk.org  Wed Jul  9 03:13:43 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 9 Jul 2025 03:13:43 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
Message-ID: <FdiFpJfYuj7XZLDV0GhmUnTrxixCXJq2P_xxhl3KBDc=.67a76370-544e-4636-b6f1-d99966244427@github.com>

On Mon, 7 Jul 2025 19:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
> 
> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26170#pullrequestreview-2999816312

From duke at openjdk.org  Wed Jul  9 03:15:51 2025
From: duke at openjdk.org (Ravi-Patel8)
Date: Wed, 9 Jul 2025 03:15:51 GMT
Subject: Integrated: 8361484: Remove duplicate font filename mappings in
 fontconfig.properties for AIX
In-Reply-To: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
References: <itAdS5KvGCJtRqIUdNMCn7QG2BOS-m0t6D38NkGV_VQ=.f2da5287-2f44-4953-8856-d420fce1a097@github.com>
Message-ID: <wVOTHCN2Zhe5AOXybPvcsL_npPQ7YVCUZhjvkGiB1jc=.66661c6d-9a62-420b-a21a-8dc485796d73@github.com>

On Mon, 16 Jun 2025 09:30:15 GMT, Ravi-Patel8 <duke at openjdk.org> wrote:

> Bug Ref: https://bugs.openjdk.org/browse/JDK-8361484
> 
> 
> The following keys are removed:
> 
> `filename.-monotype-timesnewromanwt-medium-r-normal---%d-75-75--*-gb2312.1980-0=/usr/lpp/X11/lib/X11/fonts/TrueType/tnrwt_s.ttf`
> 
> `filename.-monotype-wt_serif_sc-medium-r-normal---%d-75-75--*-iso10646-1=/usr/lpp/X11/lib/X11/fonts/TrueType/wt__s__b.ttf`
> 
> Signed-off-by: Ravi.Patel8 <Ravi.Patel8 at ibm.com>

This pull request has now been integrated.

Changeset: 19bb6ebf
Author:    Ravi-Patel8 <Ravi.Patel8 at ibm.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19bb6ebfaffc9208dbc8a125270848cb2fe37e94
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8361484: Remove duplicate font filename mappings in fontconfig.properties for AIX

Reviewed-by: serb, azvegint

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

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

From jdv at openjdk.org  Wed Jul  9 10:06:43 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 9 Jul 2025 10:06:43 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v9]
In-Reply-To: <uGPBINB7_3njht8pAnyFTOX-ltbXU_uGP1n4BXzXtQ4=.defc3081-1903-4919-9d8b-f56c06d31ea1@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <uGPBINB7_3njht8pAnyFTOX-ltbXU_uGP1n4BXzXtQ4=.defc3081-1903-4919-9d8b-f56c06d31ea1@github.com>
Message-ID: <ct4E2VNWPIRcHC02KvF9Qx5HNwiFUSZdwP3GoLYOaeA=.24283ca8-0779-420c-8d41-a136aff04c39@github.com>

On Sun, 1 Jun 2025 06:43:44 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
>> 
>> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
>> 2. The transparent pixel is non-zero
>> 3. There's more than one such consecutive frame
>> 
>> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
>> 
>> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>
> Jeremy Wood has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - 8356137: adding copyright
>  - 8356137: remove test file now that we use GifBuilder
>  - 8356137: Use new GifBuilder for 8356137 test case
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750

> > I think this is better then current approach of having check multiple times.
> 
> OK. I switched back to this approach.
> 
> (The downside being: now we'll invoke Arrays.fill(..) for _all_ gifs with that disposal method. I assume (?) gifs with this architecture/problem are a small subset of that group; but it's impossible to quantify that hunch.)

Yes and also this will happen only when transparentPixelIndex > 0.

I have again verified updated test with updated code and change looks good to me. Only thing is change should be updated to follow 80 characters per line, i see at many places it is >100 characters and difficult to read.

I have given full CI test run and will update here after the results.

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

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-3051978321

From ecaspole at openjdk.org  Wed Jul  9 15:27:39 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 9 Jul 2025 15:27:39 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <Z3Za8Q1MvHz681H5rULDJhiN6FNv6SX-Yy-hoZJUF80=.01387b02-a3a8-494e-9f95-0274205ce505@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
 <PGs-ecJTzRCARPURkRS00PECjq946Ylz6gx2QHEUxj0=.c1eab603-494d-46fd-b6d0-56b88a0743a2@github.com>
 <AOk2eJ9P6FUqODNFNv4T3qKwRQIRXatrTmHL90YP_YI=.8f2dd469-69a8-4d7a-af89-4e1515c1d134@github.com>
 <Hwnb5ZHKomN3i-EZ0fEudxTuBFXLb3ieevtCAnAJxtQ=.b9397cf4-20ed-4a4c-860a-5a6e1fed4ead@github.com>
 <-NYImJ94f_X6FR6wgZDfzdzA53dfZbEx8EzeBA5GZ3A=.e43f155f-0d0e-4f66-b0c9-73e7f10beddb@github.com>
 <Z3Za8Q1MvHz681H5rULDJhiN6FNv6SX-Yy-hoZJUF80=.01387b02-a3a8-494e-9f95-0274205ce505@github.com>
Message-ID: <MOxTlto5w19tuQXpgDv1JKhOA07Fr9WSvtJx50YEBos=.dbfb3bcc-960e-4773-82c4-0b883befedbe@github.com>

On Fri, 4 Jul 2025 00:59:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> I think we can just drop ant and leave the makefile as it is. The source/target settings are set to that low level to indicate that the source code should be compatible with older versions of the JDK. Currently, JDK 1.4 compatibility is still maintained.
>> 
>> I have supposed that this PR exists because Eric wants to use ant. Eric ?
>> 
>> I think for today's mainline, not supporting jdk7 as an out of the box target isn't a huge problem. 
>> Current javac doesn't support 7 as a target so it seems reasonable to me.
>
>> Current javac doesn't support 7 as a target so it seems reasonable to me.
> 
> That's why the makefile was parameterized, to easily set the target and source options based on the currently used minimal supported version of javac. But we may change it with a comment that 1.4 still should be supported, or something like that.

Yes when I need to work on J2DBench I usually use the ant and nbproject because I still often use NetBeans.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26077#discussion_r2195313649

From ecaspole at openjdk.org  Wed Jul  9 16:00:59 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 9 Jul 2025 16:00:59 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build [v2]
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <EsKBLtNlMOQaVkCdUIdxwdAOuY0azODr7hBnTVB9Zrg=.6e720c95-39bd-43f6-bd71-3d1b61aa394c@github.com>

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Update the version default to 8 in the Make file as Phil noticed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26077/files
  - new: https://git.openjdk.org/jdk/pull/26077/files/a2ad30c8..ab69037f

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

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

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

From prr at openjdk.org  Wed Jul  9 18:37:40 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 9 Jul 2025 18:37:40 GMT
Subject: RFR: 8361216: Do not fork javac in J2DBench ant build [v2]
In-Reply-To: <EsKBLtNlMOQaVkCdUIdxwdAOuY0azODr7hBnTVB9Zrg=.6e720c95-39bd-43f6-bd71-3d1b61aa394c@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
 <EsKBLtNlMOQaVkCdUIdxwdAOuY0azODr7hBnTVB9Zrg=.6e720c95-39bd-43f6-bd71-3d1b61aa394c@github.com>
Message-ID: <56fypCjPHTGDUWKxT277m5yF5tocM1H6LxNYKwyomCc=.115f1cf5-6f25-4695-b72f-3eef60f7c79e@github.com>

On Wed, 9 Jul 2025 16:00:59 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the version default to 8 in the Make file as Phil noticed.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26077#pullrequestreview-3002672644

From ecaspole at openjdk.org  Wed Jul  9 18:50:44 2025
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 9 Jul 2025 18:50:44 GMT
Subject: Integrated: 8361216: Do not fork javac in J2DBench ant build
In-Reply-To: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
References: <SGN0mWJJjHUwJLrmFrGdk17cuPGwG32Vxj12ju4eCts=.7ae8b1e6-3da4-4f44-87e8-0cf9cc83e71e@github.com>
Message-ID: <mNxOmy358lCeybfi6UIpJCxGEjNnX4J0q8XpbVemz5c=.eb653d00-c394-42af-bcea-d1ba41053665@github.com>

On Tue, 1 Jul 2025 19:30:21 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> Build J2DBench in ant using JAVA_HOME, not using fork to possibly pick a different javac from the PATH.

This pull request has now been integrated.

Changeset: 7282f68c
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7282f68cee22af3f65ea045fd6ada890df79ae07
Stats:     10 lines in 2 files changed: 0 ins; 5 del; 5 mod

8361216: Do not fork javac in J2DBench ant build

Reviewed-by: prr

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

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

From duke at openjdk.org  Wed Jul  9 19:09:32 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 9 Jul 2025 19:09:32 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v10]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <VkZEBVkZrfpBFniyZg1D5cDpJnXBmY-77CT-EsmNNBg=.7cbfc82f-a890-434c-9970-2350e814bc8b@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)

Jeremy Wood 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 39 additional commits since the last revision:

 - 8354646: rewrapping line breaks so text is < 80 chars
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#issuecomment-3051978321
 - Merge branch 'master' into JDK-8356137
 - 8356137: adding copyright
 - 8356137: remove test file now that we use GifBuilder
 - 8356137: Use new GifBuilder for 8356137 test case
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: Adding GifBuilder to dynamically create test file
   
   This can be used by multiple gif tests in this directory.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: trivial javadoc update
 - 8356137: only inspect last frame of gif
   
   This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
 - 8356137: remove the redundant transparency check
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2109318427
 - 8356137: flood fill saved_image at initialization
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#issuecomment-2912699099
 - ... and 29 more: https://git.openjdk.org/jdk/compare/2c88ffdc...e143c8cf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/392a9e5f..e143c8cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=08-09

  Stats: 135422 lines in 2651 files changed: 81061 ins; 33367 del; 20994 mod
  Patch: https://git.openjdk.org/jdk/pull/25044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25044/head:pull/25044

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

From aivanov at openjdk.org  Wed Jul  9 19:32:47 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 9 Jul 2025 19:32:47 GMT
Subject: RFR: 8361115: javax/swing/JComboBox/bug4276920.java unnecessarily
 throws Error instead of RuntimeException
In-Reply-To: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>
References: <pbimXhuECnIthjUWfSgrHKNuKyrCgLN0bem_MfKJfNA=.32bfa6ed-fd20-4234-b4b3-0b0f9443d490@github.com>
Message-ID: <llK7uKVAxoLOBmXEJLksmUzFslvXnsPCGJadjrx9t98=.741c3e03-e836-4d3f-8dc6-0c97d30df096@github.com>

On Tue, 1 Jul 2025 04:57:05 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Issue:
> javax/swing/JComboBox/bug4276920.java unnecessarily throws Error instead of RuntimeException whenever a test failure occurs.
> This causes unnecessary extra attention in CI systems and triggers task failures as throwing an Error will write the error message to System.err and the CI system will detect it as an 'Error' and fails the task eventually.
> But this is just a normal test failure only and just need to throw 'RuntimeException' and no need to throw an 'Error'.
> 
> Fix:
> Replace 'Error' with 'RuntimeException'
> 
> Testing:
> Tested using mach5 in all the available platforms.
> Tested manually the negative (failure) condition also and verified that its throwing 'RuntimeException' in cases of failure.

This was an unnecessary change.

The CI task failed for different reason, it timed out. Yet the task displayed the error message from the javax/swing/JComboBox/bug4276920.java test failure, which happened to be the first string that contained `Error:` prefix.

There's nothing wrong with throwing `Error` instead of `RuntimeException` to fail a test, although the latter is much more common. I even find `Error` more descriptive, and it's shorter.

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

PR Comment: https://git.openjdk.org/jdk/pull/26056#issuecomment-3053768610

From prr at openjdk.org  Wed Jul  9 20:18:38 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 9 Jul 2025 20:18:38 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
Message-ID: <emhj-T4Q_G2SE1KL7-bOJB9jMqMljj9Y0ssx8RRWiiM=.6a454f97-6a56-423a-8659-63f5f890730e@github.com>

On Mon, 7 Jul 2025 19:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
> 
> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.

The test *expects* to receive Insert (not 0) even if numlock is on ? Why is that ?

It isn't really mentioned but this about Robot, isn't it ?
What happens if a user types directly ? 

Can you please put an evaluation in the bug report.
Also is this a regression of JDK-8351907 ? Looks that way since it is reported as working in JDK 25 b23.

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

PR Comment: https://git.openjdk.org/jdk/pull/26170#issuecomment-3053879198

From duke at openjdk.org  Wed Jul  9 20:54:23 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 9 Jul 2025 20:54:23 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v11]
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)

Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/JDK-8356137' into JDK-8356137
 - 8356137: rewrapping line breaks so text is < 80 chars
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#issuecomment-3051978321

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25044/files
  - new: https://git.openjdk.org/jdk/pull/25044/files/e143c8cf..1dbbe45d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25044&range=09-10

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

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

From duke at openjdk.org  Wed Jul  9 22:37:39 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 9 Jul 2025 22:37:39 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v9]
In-Reply-To: <ct4E2VNWPIRcHC02KvF9Qx5HNwiFUSZdwP3GoLYOaeA=.24283ca8-0779-420c-8d41-a136aff04c39@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <uGPBINB7_3njht8pAnyFTOX-ltbXU_uGP1n4BXzXtQ4=.defc3081-1903-4919-9d8b-f56c06d31ea1@github.com>
 <ct4E2VNWPIRcHC02KvF9Qx5HNwiFUSZdwP3GoLYOaeA=.24283ca8-0779-420c-8d41-a136aff04c39@github.com>
Message-ID: <rnaFWfhhMpzwC4kKB2fyzR985bQ1Gw5mIgdSB_gmKd8=.4e8d4119-8a63-4baa-90b1-dc1b9b6ff4c2@github.com>

On Wed, 9 Jul 2025 10:03:02 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Only thing is change should be updated to follow 80 characters per line

OK, I re-wrapped text in the test java files.

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

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-3054307843

From azvegint at openjdk.org  Thu Jul 10 01:06:40 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 10 Jul 2025 01:06:40 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
Message-ID: <agZOSsq-V8T2lTUtGTPoRV6upUO6gPJmbGCg-DMDa20=.bc95a44f-47df-406c-ad38-6ea015b388e6@github.com>

On Mon, 7 Jul 2025 19:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
> 
> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.

> The test _expects_ to receive Insert (not 0) even if numlock is on ? Why is that ?
> It isn't really mentioned but this about Robot, isn't it ? What happens if a user types directly ?

The test doesn't care which button is pressed. It stores the keyCode-keyChar pair in a map received from the keyPressed event.
Later, it checks whether the keyChar in the subsequent keyReleased event for the same keyCode matches the keyChar in the keyPressed event for that keyCode. It just checks for consistency.

https://github.com/openjdk/jdk/blob/518536c607cb383e810ee0f50f8af44e121f4ab3/test/jdk/java/awt/event/KeyEvent/KeyCharTest/KeyCharTest.java#L45-L55

Before the fix, it was receiving:
* Numlock on: KEY_PRESSED with `keyChar=Undefined keyChar` and KEY_RELEASED with `keyChar='0'`  / NumPad-0 keyCode
* Numlock off: Undefined keyChar was received in both cases; the test didn't fail.  / Insert keyCode

After the fix, everything is consistent, and the same key events are reported as if they were pressed by a user.

> Can you please put an evaluation in the bug report.

Sure.

> Also is this a regression of JDK-8351907 ? Looks that way since it is reported as working in JDK 25 b23.

Yes, it is.

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

PR Comment: https://git.openjdk.org/jdk/pull/26170#issuecomment-3054737704

From jdv at openjdk.org  Thu Jul 10 07:22:41 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 10 Jul 2025 07:22:41 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v11]
In-Reply-To: <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>
Message-ID: <WZIqf_ghVEHF__MJfxpSbNLOdLyZHkXsCkO5I8DXdSU=.9d51beec-5cd9-4229-9cc0-79c16abac266@github.com>

On Wed, 9 Jul 2025 20:54:23 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
>> 
>> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
>> 2. The transparent pixel is non-zero
>> 3. There's more than one such consecutive frame
>> 
>> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
>> 
>> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://pixabay.com/gifs/cat-kitten-black-cats-pet-animal-20315/
>> https://free-gifs.org/gif/CC0-3D
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8356137' into JDK-8356137
>  - 8356137: rewrapping line breaks so text is < 80 chars
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#issuecomment-3051978321

CI test run is green.
LGTM.

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25044#pullrequestreview-3004299588

From jdv at openjdk.org  Thu Jul 10 09:21:41 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 10 Jul 2025 09:21:41 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v4]
In-Reply-To: <qE2zZi7If266h2g2L2YoIGYpioVh8fDTArKuo358OFU=.4d6cf355-85a2-4f53-9890-75c59093b8e1@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <qE2zZi7If266h2g2L2YoIGYpioVh8fDTArKuo358OFU=.4d6cf355-85a2-4f53-9890-75c59093b8e1@github.com>
Message-ID: <vhdR76OUqHUyrcwWL91NWH5FTx1f5htRWkheWketH7A=.40e58ea7-1db2-4d6e-bf3d-f7e68768a893@github.com>

On Sun, 1 Jun 2025 07:13:14 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
>> 
>> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
>> 
>> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
>> 2. [8356137](https://github.com/openjdk/jdk/pull/25044)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
>> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
>> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
>> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
>
> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: trivial javadoc update
>  - 8356137: only inspect last frame of gif
>    
>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270

src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 401:

> 399:             if (isSimple) {
> 400:                 for (int a = 0; a < saved_image.length; a++) {
> 401:                     if ((saved_image[a] & 0xff) == trans_pixel) {

This check is scanning whole saved image(until 241 index in this scenario) for each scanline. So for each GIF frame we are running this loop height times.

We can maintain a common boolean variable and verify isSimple/not just before parseImage() call. This will make sure that we perform this check only once per GIF frame.

To verify, updated the code to move this check inside readImage() and just before parseImage() call and it works fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25264#discussion_r2197097522

From abaya at openjdk.org  Thu Jul 10 11:33:16 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 10 Jul 2025 11:33:16 GMT
Subject: RFR: 8361839 : Problemlist BogusFocusableWindowState due to failures
 in the CI pipeline
Message-ID: <Zj6X-WJwLnHGAi8DM6YCfzfzwR-RP821ESRWvneKWDM=.19e8c4ad-1143-4df4-bdb7-10e6e9d203a5@github.com>

Problemlisting BogusFocusableWindowState test due to recurrent failures on Linux

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

Commit messages:
 - Problimlisting BogusFocusableWindowState

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

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

From rgupta at openjdk.org  Thu Jul 10 11:49:26 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Thu, 10 Jul 2025 11:49:26 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v3]
In-Reply-To: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
Message-ID: <1yh7ip1u4XcwKCLJ5jlz6jd-uHmAIFyBPmV366S_b0A=.37469cf7-07ea-4a69-8ec2-bf5f7b06e9cb@github.com>

> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
> 
> 
>  finally {
>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>         }
>     public static void disposeFrame() {
>         if (frame != null) {
>             frame.dispose();
>             frame = null;
>         }
>     }

Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:

  8361067: Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26043/files
  - new: https://git.openjdk.org/jdk/pull/26043/files/1a2cb6e0..417d94e1

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

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

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

From aivanov at openjdk.org  Thu Jul 10 11:56:37 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 10 Jul 2025 11:56:37 GMT
Subject: RFR: 8361839 : Problemlist BogusFocusableWindowState due to
 failures in the CI pipeline
In-Reply-To: <Zj6X-WJwLnHGAi8DM6YCfzfzwR-RP821ESRWvneKWDM=.19e8c4ad-1143-4df4-bdb7-10e6e9d203a5@github.com>
References: <Zj6X-WJwLnHGAi8DM6YCfzfzwR-RP821ESRWvneKWDM=.19e8c4ad-1143-4df4-bdb7-10e6e9d203a5@github.com>
Message-ID: <0I4ObMKHsUQY5FuRVsd8We9wUfCK3eqwtehOVIyDMvQ=.73b2c4e8-c41f-4e10-b7da-72d626842bc0@github.com>

On Thu, 10 Jul 2025 10:32:19 GMT, Anass Baya <abaya at openjdk.org> wrote:

> Problemlisting BogusFocusableWindowState test due to recurrent failures on Linux

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26241#pullrequestreview-3005343008

From duke at openjdk.org  Thu Jul 10 12:38:40 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 12:38:40 GMT
Subject: RFR: 8361839 : Problemlist BogusFocusableWindowState due to
 failures in the CI pipeline
In-Reply-To: <Zj6X-WJwLnHGAi8DM6YCfzfzwR-RP821ESRWvneKWDM=.19e8c4ad-1143-4df4-bdb7-10e6e9d203a5@github.com>
References: <Zj6X-WJwLnHGAi8DM6YCfzfzwR-RP821ESRWvneKWDM=.19e8c4ad-1143-4df4-bdb7-10e6e9d203a5@github.com>
Message-ID: <MP42lgemCHbWHmtuBhi7cAfxcXkk_Qh0qOX303sIU64=.775f953f-dc17-4b3a-8d0f-5cf4281cfe5e@github.com>

On Thu, 10 Jul 2025 10:32:19 GMT, Anass Baya <abaya at openjdk.org> wrote:

> Problemlisting BogusFocusableWindowState test due to recurrent failures on Linux

@anass-baya 
Your change (at version b315b72f8e17064888eb215fb30a16f085a21a99) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26241#issuecomment-3057272915

From abaya at openjdk.org  Thu Jul 10 13:09:43 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 10 Jul 2025 13:09:43 GMT
Subject: Integrated: 8361839 : Problemlist BogusFocusableWindowState due to
 failures in the CI pipeline
In-Reply-To: <Zj6X-WJwLnHGAi8DM6YCfzfzwR-RP821ESRWvneKWDM=.19e8c4ad-1143-4df4-bdb7-10e6e9d203a5@github.com>
References: <Zj6X-WJwLnHGAi8DM6YCfzfzwR-RP821ESRWvneKWDM=.19e8c4ad-1143-4df4-bdb7-10e6e9d203a5@github.com>
Message-ID: <-a6wDUQi_COIOM2SEu3viPv4yg4a_FkyewlpreUztS4=.16c661c2-24ca-4668-b41c-0c1251134464@github.com>

On Thu, 10 Jul 2025 10:32:19 GMT, Anass Baya <abaya at openjdk.org> wrote:

> Problemlisting BogusFocusableWindowState test due to recurrent failures on Linux

This pull request has now been integrated.

Changeset: f7352750
Author:    Anass Baya <abaya at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f73527502177a8f050272d6157ccbec3e9840bc8
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8361839: Problemlist BogusFocusableWindowState due to failures in the CI pipeline

Reviewed-by: aivanov

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

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

From achung at openjdk.org  Thu Jul 10 15:29:25 2025
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 10 Jul 2025 15:29:25 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v23]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <OWeQEnalivyjSTJibr3FF8OVLIHDdEbq6eL4GtNPEnM=.6125e11d-8adf-4c33-b091-a18384a6e203@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - update robot specs
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
 - remove ER from remaining modal test
 - remove /lib/client/ from tests with ER removed
 - update tests, remove extended robot from some tests
 - update tests
 - synchronized for type(char)
 - migrate type(char) method
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
 - remove specified numbers in constant fields, add exception to documentation in glide
 - ... and 22 more: https://git.openjdk.org/jdk/compare/3bcbcc57...c02d4183

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

Changes: https://git.openjdk.org/jdk/pull/22044/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=22
  Stats: 1046 lines in 244 files changed: 234 ins; 447 del; 365 mod
  Patch: https://git.openjdk.org/jdk/pull/22044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044

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

From abhiscxk at openjdk.org  Thu Jul 10 16:19:48 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 10 Jul 2025 16:19:48 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v3]
In-Reply-To: <1yh7ip1u4XcwKCLJ5jlz6jd-uHmAIFyBPmV366S_b0A=.37469cf7-07ea-4a69-8ec2-bf5f7b06e9cb@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <1yh7ip1u4XcwKCLJ5jlz6jd-uHmAIFyBPmV366S_b0A=.37469cf7-07ea-4a69-8ec2-bf5f7b06e9cb@github.com>
Message-ID: <S7I_UAizoXZ7lSzcwV3BWG82TILK1d5u2zeAhxalKI4=.57da182d-7580-4b49-9724-88194fba32eb@github.com>

On Thu, 10 Jul 2025 11:49:26 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: Review comments

Copyright year needs to update.
Space formatting is required throughout the code. e.g. L58, L62 etc...
Add @Overide for the overridden methods.
SOP statement inside mouseDragged contains commented code... can be removed.
SOP inside mousePressed and mouseReleased can be consistent with other APIs, `Pressed` instead of `>>>`.
Commented code can be removed.
Object initialization and setting up the mouse listener can be moved to constructor. I don't think extending Frame is required.

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 101:

> 99:             robot.delay(1000);
> 100:             Point centerFrame = new Point(frame.getLocationOnScreen().x + frame.getWidth()/2, frame.getLocationOnScreen().y + frame.getHeight()/2);
> 101:             Point outboundsFrame = new Point(frame.getLocationOnScreen().x + frame.getWidth()*3/2, frame.getLocationOnScreen().y + frame.getHeight()/2);

should be accessed on EDT.

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

PR Review: https://git.openjdk.org/jdk/pull/26043#pullrequestreview-3006402971
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2198157732

From duke at openjdk.org  Thu Jul 10 21:20:07 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 10 Jul 2025 21:20:07 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v5]
In-Reply-To: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
Message-ID: <SWwlsyVwR91GzaqjGg7r7DPBIVJ_tGNQIBD_wwxfVC4=.97d1d744-ca58-4fd7-8fc5-4a9175fa15cc@github.com>

> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
> 
> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
> 
> This bug can be observed reading these gif animations:
> 
> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l

Jeremy Wood 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 29 additional commits since the last revision:

 - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
 - Merge branch 'master' into JDK-8357034
 - 8356320: Use new GifBuilder and remove ukraine-flag.gif
   
   This is an extension of work for this PR:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: adding copyright
 - 8356137: Adding GifBuilder to dynamically create test file
   
   This can be used by multiple gif tests in this directory.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: trivial javadoc update
 - 8356137: only inspect last frame of gif
   
   This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
 - 8356137: Adding copyright to GifComparison
 - 8357034: fixing classname
 - 8356320: trivial whitespace and comment changes
 - ... and 19 more: https://git.openjdk.org/jdk/compare/8e1cfed5...b8a8bf7d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25264/files
  - new: https://git.openjdk.org/jdk/pull/25264/files/3750e58e..b8a8bf7d

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

  Stats: 135354 lines in 2649 files changed: 81027 ins; 33376 del; 20951 mod
  Patch: https://git.openjdk.org/jdk/pull/25264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25264/head:pull/25264

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

From prr at openjdk.org  Thu Jul 10 21:44:43 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 10 Jul 2025 21:44:43 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v11]
In-Reply-To: <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>
Message-ID: <bcU-iQyDBfUNXVVrKrdWKmJvfSdyIBsfhliI1-zs4Vg=.1ebacc20-dc98-492e-8fa0-e853dbf2d59d@github.com>

On Wed, 9 Jul 2025 20:54:23 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
>> 
>> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
>> 2. The transparent pixel is non-zero
>> 3. There's more than one such consecutive frame
>> 
>> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
>> 
>> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://pixabay.com/gifs/cat-kitten-black-cats-pet-animal-20315/
>> https://free-gifs.org/gif/CC0-3D
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8356137' into JDK-8356137
>  - 8356137: rewrapping line breaks so text is < 80 chars
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#issuecomment-3051978321

LGTM.
Might get the award for "best original test".
I did modify the test to dump the frames being generated and the accumulated image, just so I could see.
Maybe you could add such a feature as a debugging option in one of the follow-on PRs.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25044#pullrequestreview-3007487527

From duke at openjdk.org  Thu Jul 10 21:49:40 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Thu, 10 Jul 2025 21:49:40 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out
In-Reply-To: <EnXD0-xl2uurJuu6uvgR5Lgc-GCssvLva19S8OTi1Q0=.18e687ef-a14f-4d6f-af11-d5236a232169@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
 <EnXD0-xl2uurJuu6uvgR5Lgc-GCssvLva19S8OTi1Q0=.18e687ef-a14f-4d6f-af11-d5236a232169@github.com>
Message-ID: <H8ACnUN9Ieki-Fmn5gccd4iTfjRxqbR-N-y5qnrxDqw=.ae7215cd-7e95-4c78-93ba-dfe244efb2c4@github.com>

On Tue, 8 Jul 2025 22:44:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> The fix for the https://bugs.openjdk.org/browse/JDK-8251928.
>> 
>> **Description**.
>> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob.
>> 
>> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ):
>> 1. Convert the user-space point, size, or rectangle value to device space coordinates;
>> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary;
>> 3. Convert the normalized value back to user space;
>> 4. Draw your content using the adjusted value. 
>>     
>> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI.
>> The 2-nd step is a drawing process in the java code (without changes).
>> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI.
>> The 4-th step is a drawing process in the native code (without changes).
>> 
>> **Tests**.
>> I run all tests from javax.print package and there is no any regression.
>> New test covers macOS and Linux only because we know its default DPI - 300.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 821:
> 
>> 819:                 Graphics2D delegate = new SunGraphics2D(sd, Color.black, Color.white, defaultFont);
>> 820:                 if (scaleX != 1 && scaleY != 1) {
>> 821:                     ((SunGraphics2D) delegate).setDevClip(0, 0,
> 
> Only SunGraphics2D itself uses this (internally).
> Regardless of the scale, if the clip needs to be set, to the page dimensions, it must be set somewhere already. So this feels like it might be the wrong way to do this.
> Why did you do it this way ?

To achieve good image printing quality, the printed image must be drawn using the printer's DPI or close to it if the DPI isn't known.
The page is rendered in the following sequence 
  "User Image" ->  CPrinterGraphics -> SunGraphics2D -> CPrinterSurfaceData -> OSXSurfaceData -> "Native macOS User space".
  
CPrinterSurfaceData, OSXSurfaceData, and "Native macOS User space" from the rendering sequence are tightly coupled and contain data that is used in both native code and java, as well as CPrinterSurfaceData and OSXSurfaceData reflect the user space provided by macOS for rendering, including size and DPI, which is convenient and expected, and all the work on translations from the user space to the device space are performed automatically by macOS. Thus, I assumed that it is not reasonable to change anything in CPrinterSurfaceData and OSXSurfaceData.

To enable the user to determine the actual DPI of the printer, it remains possible to make changes to CPrinterGraphics or SunGraphics2D. I decided to add changes to SunGraphics2D because it is closer in the chain to rendering in macOS, and it also provides means for setting the necessary parameters through the existing public methods (setDevClip), and perform the reverse translation into the macOS user space in native code using scale methods specifically designed for this purpose.
It is possible to add an additional constructor to SunGraphics2D that takes into account the necessary scaling, and thus avoid using setDevClip, but this changes the actual API of SunGraphics2D, which I tried to avoid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2198816927

From duke at openjdk.org  Thu Jul 10 22:21:39 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 10 Jul 2025 22:21:39 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v4]
In-Reply-To: <vhdR76OUqHUyrcwWL91NWH5FTx1f5htRWkheWketH7A=.40e58ea7-1db2-4d6e-bf3d-f7e68768a893@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <qE2zZi7If266h2g2L2YoIGYpioVh8fDTArKuo358OFU=.4d6cf355-85a2-4f53-9890-75c59093b8e1@github.com>
 <vhdR76OUqHUyrcwWL91NWH5FTx1f5htRWkheWketH7A=.40e58ea7-1db2-4d6e-bf3d-f7e68768a893@github.com>
Message-ID: <21kaQq4czyJNuYBFMDk-nTw_nP4vB4F8aqAEzpz4XwU=.55d9b13b-3432-4abf-9fd9-274f7a781f2e@github.com>

On Thu, 10 Jul 2025 09:18:47 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>>    
>>    This is an extension of work for this PR:
>>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>>  - 8356137: adding copyright
>>  - 8356137: Adding GifBuilder to dynamically create test file
>>    
>>    This can be used by multiple gif tests in this directory.
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>>  - 8356137: trivial javadoc update
>>  - 8356137: only inspect last frame of gif
>>    
>>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
>
> src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 401:
> 
>> 399:             if (isSimple) {
>> 400:                 for (int a = 0; a < saved_image.length; a++) {
>> 401:                     if ((saved_image[a] & 0xff) == trans_pixel) {
> 
> This check is scanning whole saved image(until 241 index in this scenario) for each scanline. So for each GIF frame we are running this loop height times.
> 
> We can maintain a common boolean variable and verify isSimple/not just before parseImage() call. This will make sure that we perform this check only once per GIF frame.
> 
> To verify, updated the code to move this check inside readImage() and just before parseImage() call and it works fine.

Good point. I [added the field](https://github.com/openjdk/jdk/pull/25264/commits/b8a8bf7d3d81372f686d48aec2a1733955ebd545) `isSimpleSavedImageComparison`. In addition to the unit test I also tested the gifs mentioned in the PR description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25264#discussion_r2198870961

From duke at openjdk.org  Thu Jul 10 22:30:40 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Thu, 10 Jul 2025 22:30:40 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v11]
In-Reply-To: <bcU-iQyDBfUNXVVrKrdWKmJvfSdyIBsfhliI1-zs4Vg=.1ebacc20-dc98-492e-8fa0-e853dbf2d59d@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>
 <bcU-iQyDBfUNXVVrKrdWKmJvfSdyIBsfhliI1-zs4Vg=.1ebacc20-dc98-492e-8fa0-e853dbf2d59d@github.com>
Message-ID: <BSZZp87Uod9Q0gmakEMh9puiglmC0LxOY6gQrXpqLTc=.c71562b2-0a1b-41a4-aec0-08a96f8f66cb@github.com>

On Thu, 10 Jul 2025 21:41:51 GMT, Phil Race <prr at openjdk.org> wrote:

> Maybe you could add such a feature as a debugging option in one of the follow-on PRs.

Sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-3059329759

From duke at openjdk.org  Thu Jul 10 22:30:41 2025
From: duke at openjdk.org (duke)
Date: Thu, 10 Jul 2025 22:30:41 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v11]
In-Reply-To: <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>
Message-ID: <kOLyFACxffEjeCxNpz2W6yP6f8ZFHR_bK_dnW21pY7Q=.c1c02582-239f-4c0c-bb65-986510256e88@github.com>

On Wed, 9 Jul 2025 20:54:23 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
>> 
>> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
>> 2. The transparent pixel is non-zero
>> 3. There's more than one such consecutive frame
>> 
>> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
>> 
>> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://pixabay.com/gifs/cat-kitten-black-cats-pet-animal-20315/
>> https://free-gifs.org/gif/CC0-3D
>
> Jeremy Wood has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/JDK-8356137' into JDK-8356137
>  - 8356137: rewrapping line breaks so text is < 80 chars
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#issuecomment-3051978321

@mickleness 
Your change (at version 1dbbe45d400546c31d2fbbcfe4008ed124609212) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-3059331972

From honkar at openjdk.org  Thu Jul 10 23:35:38 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 10 Jul 2025 23:35:38 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <agZOSsq-V8T2lTUtGTPoRV6upUO6gPJmbGCg-DMDa20=.bc95a44f-47df-406c-ad38-6ea015b388e6@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
 <agZOSsq-V8T2lTUtGTPoRV6upUO6gPJmbGCg-DMDa20=.bc95a44f-47df-406c-ad38-6ea015b388e6@github.com>
Message-ID: <xhtBYqXidGsodI4xt27FfeQX2R3ySGPAk-DOJ3sWx_0=.6ab958c9-3df7-4620-8184-2b7e65717314@github.com>

On Thu, 10 Jul 2025 01:02:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
>> 
>> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.
>
>> The test _expects_ to receive Insert (not 0) even if numlock is on ? Why is that ?
>> It isn't really mentioned but this about Robot, isn't it ? What happens if a user types directly ?
> 
> The test doesn't care which button is pressed. It stores the keyCode-keyChar pair in a map received from the keyPressed event.
> Later, it checks whether the keyChar in the subsequent keyReleased event for the same keyCode matches the keyChar in the keyPressed event for that keyCode. It just checks for consistency.
> 
> https://github.com/openjdk/jdk/blob/518536c607cb383e810ee0f50f8af44e121f4ab3/test/jdk/java/awt/event/KeyEvent/KeyCharTest/KeyCharTest.java#L45-L55
> 
> Before the fix, it was receiving:
> * Numlock on: KEY_PRESSED with `keyChar=Undefined keyChar` and KEY_RELEASED with `keyChar='0'`  / NumPad-0 keyCode
> * Numlock off: Undefined keyChar was received in both cases; the test didn't fail.  / Insert keyCode
> 
> After the fix, everything is consistent, and the same key events are reported as if they were pressed by a user.
> 
>> Can you please put an evaluation in the bug report.
> 
> Sure.
> 
>> Also is this a regression of JDK-8351907 ? Looks that way since it is reported as working in JDK 25 b23.
> 
> Yes, it is.

@azvegint This is in regards to the regression test for this fix. The existing test `/awt/event/KeyEvent/KeyCharTest/KeyCharTest.java` does not correctly reproduce the issue when Numlock is not "ON" on the testing system.

To better replicate the problem without the fix, adding a new test for this fix is good.
- Test only the Numpad keys (0x60 to 0x6F)
- Automate the Numlock 'On' and reset it at the end of the test probably in the finally block


robot.keyPress(KeyEvent.VK_NUM_LOCK);
robot.keyRelease(KeyEvent.VK_NUM_LOCK);
for(int vkey = 0x60; vkey < 0x6F; vkey++) {
    try {
        robot.keyPress(vkey);
        robot.keyRelease(vkey);
        System.out.println(KeyEvent.getKeyText(vkey) + " " + vkey);
    } catch (RuntimeException e) {
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/26170#issuecomment-3059527965

From azvegint at openjdk.org  Fri Jul 11 03:31:35 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 11 Jul 2025 03:31:35 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered [v2]
In-Reply-To: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
Message-ID: <tQFLQ2UgBUW8ntAs6foEBN575El4JaVzhhjjS_8DffA=.4b44f63b-86d2-438d-a81c-e7971843b623@github.com>

> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
> 
> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  make sure to test both numpad states

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26170/files
  - new: https://git.openjdk.org/jdk/pull/26170/files/7096b725..db92a1fb

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

  Stats: 34 lines in 1 file changed: 16 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26170/head:pull/26170

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

From azvegint at openjdk.org  Fri Jul 11 03:31:36 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 11 Jul 2025 03:31:36 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <xhtBYqXidGsodI4xt27FfeQX2R3ySGPAk-DOJ3sWx_0=.6ab958c9-3df7-4620-8184-2b7e65717314@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
 <agZOSsq-V8T2lTUtGTPoRV6upUO6gPJmbGCg-DMDa20=.bc95a44f-47df-406c-ad38-6ea015b388e6@github.com>
 <xhtBYqXidGsodI4xt27FfeQX2R3ySGPAk-DOJ3sWx_0=.6ab958c9-3df7-4620-8184-2b7e65717314@github.com>
Message-ID: <ipnU7QwBE81ju7q_7wGHI-TsFnwIgaYfyrZ9psJW17E=.80071b49-456e-40eb-abc8-0656fea48092@github.com>

On Thu, 10 Jul 2025 23:33:21 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> To better replicate the problem without the fix, adding a new test for this changeset might be a good idea.

I don't think a new test is necessary. I updated the existing one.

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

PR Comment: https://git.openjdk.org/jdk/pull/26170#issuecomment-3060240574

From serb at openjdk.org  Fri Jul 11 03:59:18 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 11 Jul 2025 03:59:18 GMT
Subject: RFR: 8359380: Rework deferral profile logic after JDK-8346465
Message-ID: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>

The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.

After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.

This patch includes two changes:

1.  We [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.

2.  While implementing the logic above I noticed a [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I?ve added a new test case that specifically verifies this behavior.

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

Commit messages:
 - pdi->bpi
 - Update workaround for 8272860
 - 8359380: Rework deferral profile logic after JDK-8346465

Changes: https://git.openjdk.org/jdk/pull/26179/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26179&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8359380
  Stats: 312 lines in 9 files changed: 192 ins; 72 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/26179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26179/head:pull/26179

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

From serb at openjdk.org  Fri Jul 11 03:59:18 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 11 Jul 2025 03:59:18 GMT
Subject: RFR: 8359380: Rework deferral profile logic after JDK-8346465
In-Reply-To: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
References: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
Message-ID: <C6EAUpmM0tiO3hcqdNaAuZNmR8ziY7bwPCZZY87wpk8=.25b07331-b6c9-44e5-af42-89d60a0de9e5@github.com>

On Tue, 8 Jul 2025 05:26:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.
> 
> After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.
> 
> This patch includes two changes:
> 
> 1.  We [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.
> 
> 2.  While implementing the logic above I noticed a [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I?ve added a new test case that specifically verifies this behavior.

test/jdk/java/awt/color/CheckDefaultProperties.java line 39:

> 37:  * @bug 8256321 8359380
> 38:  * @summary Verifies built-in profile properties are the same before and after
> 39:  *          activation and in copies of built-in profiles

The test compared data from the lightweight object with the actual data used after the profile is fully loaded. Since we now always use the lightweight object, I had to create a copy of the standard profile to make sure the actual profile data is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26179#discussion_r2199427604

From jdv at openjdk.org  Fri Jul 11 05:47:42 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 11 Jul 2025 05:47:42 GMT
Subject: RFR: 8356137: GifImageDecode can produce opaque image when
 disposal method changes [v11]
In-Reply-To: <bcU-iQyDBfUNXVVrKrdWKmJvfSdyIBsfhliI1-zs4Vg=.1ebacc20-dc98-492e-8fa0-e853dbf2d59d@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
 <GrIPE4WvZUXaz-YerIxxrl35AuTdWZ2YnRVpBPTR5dc=.178090df-01d4-4d4d-a72d-c09daac61f30@github.com>
 <bcU-iQyDBfUNXVVrKrdWKmJvfSdyIBsfhliI1-zs4Vg=.1ebacc20-dc98-492e-8fa0-e853dbf2d59d@github.com>
Message-ID: <m4Ush0UyUeQeUx_GLlLJ_qA1J6izRTfWDpzIFZhfx90=.c918a2b3-c550-4fd2-a079-ffdbe7c83cf2@github.com>

On Thu, 10 Jul 2025 21:41:51 GMT, Phil Race <prr at openjdk.org> wrote:

> I did modify the test to dump the frames being generated and the accumulated image, just so I could see. Maybe you could add such a feature as a debugging option in one of the follow-on PRs.

Followed same approach. As mentioned its better to add this image dumping logic for debugging in other PR's.

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

PR Comment: https://git.openjdk.org/jdk/pull/25044#issuecomment-3060662865

From duke at openjdk.org  Fri Jul 11 05:50:50 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 11 Jul 2025 05:50:50 GMT
Subject: Integrated: 8356137: GifImageDecode can produce opaque image when
 disposal method changes
In-Reply-To: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
References: <YAq_zWKmHNQDRLrI7LJ-pAMIwKSV8cmc3MJYs-TcEbU=.5078026f-71be-438e-85f0-eb2b021fb01f@github.com>
Message-ID: <4NxdpbPachy5I9seF6mfkkLQq8L3efwcYQ9dH5fWOu8=.d9d978fe-36b6-49ec-8b7b-1e8c49f4c790@github.com>

On Mon, 5 May 2025 17:07:11 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> This resolves a gif parsing bug where an unwanted opaque rectangle could appear under these conditions:
> 
> 1. The disposal method for frames is 1 (meaning "do not dispose", aka "DISPOSAL_SAVE")
> 2. The transparent pixel is non-zero
> 3. There's more than one such consecutive frame
> 
> Previously: the GifImageDecoder would leave the saved_image pixels as zero when they were supposed to be transparent. This works great if the transparent pixel index is zero, but it flood fills the background of your frame with the zeroeth color otherwise.
> 
> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. [8356137](https://github.com/openjdk/jdk/pull/25044) (this one)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
> 
> This bug can be observed reading these gif animations:
> 
> https://pixabay.com/gifs/cat-kitten-black-cats-pet-animal-20315/
> https://free-gifs.org/gif/CC0-3D

This pull request has now been integrated.

Changeset: 529049be
Author:    jeremy <jeremy.wood at mac.com>
Committer: Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/529049be6b6b39651713d256bb4a6efb7d822674
Stats:     618 lines in 4 files changed: 617 ins; 0 del; 1 mod

8356137: GifImageDecode can produce opaque image when disposal method changes

Reviewed-by: jdv, prr

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

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

From jdv at openjdk.org  Fri Jul 11 06:40:42 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 11 Jul 2025 06:40:42 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v5]
In-Reply-To: <SWwlsyVwR91GzaqjGg7r7DPBIVJ_tGNQIBD_wwxfVC4=.97d1d744-ca58-4fd7-8fc5-4a9175fa15cc@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <SWwlsyVwR91GzaqjGg7r7DPBIVJ_tGNQIBD_wwxfVC4=.97d1d744-ca58-4fd7-8fc5-4a9175fa15cc@github.com>
Message-ID: <cDHvz_uvdt-uIQy2OF8eiebV85AcVsCLNcPf8OOSv8Q=.be12ce4a-05bd-4ff5-878e-53e98df1bc6d@github.com>

On Thu, 10 Jul 2025 21:20:07 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
>> 
>> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
>> 
>> I wrote four PRs that share the GifComparison class in this PR. Once any of them clear code review the other PRs will be much simpler:
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
>> 2. [8356137](https://github.com/openjdk/jdk/pull/25044)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
>> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
>> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
>> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
>
> Jeremy Wood 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 29 additional commits since the last revision:
> 
>  - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
>  - Merge branch 'master' into JDK-8357034
>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: trivial javadoc update
>  - 8356137: only inspect last frame of gif
>    
>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
>  - 8356137: Adding copyright to GifComparison
>  - 8357034: fixing classname
>  - 8356320: trivial whitespace and comment changes
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/9de36470...b8a8bf7d

Latest change looks good to me. I will run CI tests and update.
Also if we can add debugging option to dump image as discussed here : https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527 it would be nice.

Also we need to merge latest master into this PR since test utility changes are already integrated.

src/java.desktop/share/classes/sun/awt/image/GifImageDecoder.java line 598:

> 596:         }
> 597: 
> 598:         isSimpleSavedImageComparison = saved_image != null && model.equals(saved_model);

Looks like we can ignore `trans_pixel >= 0 && !curframe.initialframe` check here.

I see that saved model will be null for initial frame at this point in code & if trans_pixel changes `model.equals(saved_model)` fails. So current set of checks suffice.

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

PR Comment: https://git.openjdk.org/jdk/pull/25264#issuecomment-3060816867
PR Comment: https://git.openjdk.org/jdk/pull/25264#issuecomment-3060820975
PR Review Comment: https://git.openjdk.org/jdk/pull/25264#discussion_r2199763038

From abhiscxk at openjdk.org  Fri Jul 11 07:04:40 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 11 Jul 2025 07:04:40 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <72C1WaCPTwiQ960VYIcvf_pp_42cyvQSHrQdhSmLfGU=.98079958-d0d2-435a-bbc7-e75dcf55f0d2@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
 <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
 <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>
 <DNvqxX-AkQiCJYU3HGUh9Odm1kDYi4rw5DKshsbCRV0=.65931a07-bda4-4534-b65a-d206b9d02c72@github.com>
 <9Gpzi9EC2qKmhM7NPkpzBvD7DnL2b9ou5AgXOI1JB4o=.4420fad2-f732-4f37-a33c-4cae501242c1@github.com>
 <3Zqat_6_DwtqGjxNva7tUzaXPntvp5giE1dMrlSRwJo=.d081d6a5-a7e3-46f3-9108-f159ee08553a@github.com>
 <72C1WaCPTwiQ960VYIcvf_pp_42cyvQSHrQdhSmLfGU=.98079958-d0d2-435a-bbc7-e75dcf55f0d2@github.com>
Message-ID: <WPvzinxBnR-M-HJHOrhvCJb-k1-zI2jUvtabqtNJqe8=.1b2b3c8d-56bf-4852-ba36-5b4740a68df9@github.com>

On Tue, 8 Jul 2025 08:28:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> The accessible class created for a java role `pagetab` i.e. a tab component is `CommonComponentAccessibility`.
>> The parent for `pagetab` is `TabGroupAccessibility` and the object returned from `rowRolesMapForParent`  is `null` for `TabGroupAccessibility` in `getComponentAccessibilityClass` method. Since there is no entry in the `rolesMap` for the `pagetab` role, the returned class is `CommonComponentAccessibility`.
>> So, the `accessibilityRoleDescription` API is invoked from `CommonComponentAccessibility` and not from `TabButtonAccessibility`.
>
> Thank you for the reference! However, I would like to advise you to thoroughly examine the code of TabGroupAccessibility. This is because it has its own implementations for creating child components.
> 
> Therefore, I am once again asking you to try to investigate the situation in more detail. There is a possibility that the mechanism is broken, and TabGroupAccessibility is not being created or used at all, which is incorrect.
> 
> Additionally, all objects in the hierarchy of native objects inherit from CommonComponentAccessibility in one way or another. If the accessibilityRoleDescription selector is not defined in TabGroupAccessibility, it may not be called.
> 
> I don?t have a Mac at hand right now; otherwise, I would debug this case myself and provide more detailed assistance.

TabButtonAccessibility is initialized in TabGroupAccessibility but since TabButtonAccessibility is not exposed to accessible system (i.e. not createdwithaccessible) and hence a11y subsystem in unable to invoke the method.

> TabGroupAccessibility is not being created or used at all, which is incorrect.

TabGroupAccessibility does get created and the APIs are invoked by a11y subsystem. Once the accessibilityRoleDescription selector is defined in TabGroupAccessibility, it gets called but only when the self javarole is `pagetablist`.

After adding an entry for TabButtonAccessibility in rolesMap`[rolesMap setObject:@"TabButtonAccessibility" forKey:@"pagetab"]`, creates an accessible component for TabButtonAccessibility instead of CommonComponentAccessibility and is exposed to get invoked by a11y client. Then accessibilityRoleDescription API is invoked by a11y client.

But I am yet to find if there is any repercussion of adding the entry for TabButtonAccessibility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2199824512

From serb at openjdk.org  Fri Jul 11 07:26:42 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 11 Jul 2025 07:26:42 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character
In-Reply-To: <ffs8vunXkpI7S2AvIXQuLI8n7gnprLgbqg-0IfehNYY=.3521aea5-2740-4daf-994d-473bcec17c1e@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <KKjs4kAJW8kZE99lSEYpcOXyPvCxyNRfUQ6mB3fEYX0=.23a59cb6-21db-4b63-a844-96ddb1da14a1@github.com>
 <K8BRT3nS8fc0MJ6h3P1XNm_LNOwuhnxcZ-IqfiTDIxY=.94afafd8-b860-4426-9a9f-0bdf021062cc@github.com>
 <Cfrn8_ovavY9WJeSpmYju8k1I2jXg07XU-ON8DPhGZM=.39a0daf6-4150-406b-8add-e38b409318cd@github.com>
 <RTpQD-ESC1E5Gh_Q9ztd2cj7qgVri9aEyusuEzPSTps=.71b33672-0159-4699-ae7e-9c1381d18e87@github.com>
 <XeFNblE30cLkztzO4LugH6q2a7RpXkL6SWup38sWZzk=.e2b212a2-0017-4f0b-98ef-455752f8e007@github.com>
 <ffs8vunXkpI7S2AvIXQuLI8n7gnprLgbqg-0IfehNYY=.3521aea5-2740-4daf-994d-473bcec17c1e@github.com>
Message-ID: <LjwQFRWAE0Q1namufMXWAQi__-1_Pa_KmLE8MgErzEc=.1bb145d7-9c65-435e-8d1c-9de27c19fb4b@github.com>

On Mon, 7 Jul 2025 15:42:47 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>Something like getBeforeIndex shouldn't be used to retrieve the last character or word or sentence and similar for getAfterIndex and getAtIndex APIs.

It might be useful

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3060996070

From aivanov at openjdk.org  Fri Jul 11 09:40:42 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 11 Jul 2025 09:40:42 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts
In-Reply-To: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
Message-ID: <5TRU7CRYnFpgQ3LaA1DBM6017CC8Lp-G8craQZcr9xk=.d15840a3-f549-4be9-862a-9f1a88b1614b@github.com>

On Mon, 9 Jun 2025 02:36:44 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
> 
> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)

Changes requested by aivanov (Reviewer).

src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 1:

> 1: /*

Please, update the copyright year.

test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 76:

> 74:                 JComponent.WHEN_FOCUSED,
> 75:                 JComponent.WHEN_ANCESTOR_OF_FOCUSED_COMPONENT
> 76:         }) {

The array with input map types could be a static constant just above `runTest` method.

test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 93:

> 91:                         actionBinding == DefaultEditorKit.nextWordAction ||
> 92:                         actionBinding == DefaultEditorKit.selectionPreviousWordAction ||
> 93:                         actionBinding == DefaultEditorKit.selectionNextWordAction ) {

Does it make sense to put the actions in a list or array? Then `listOfActions.contains(actionBinding)` instead of this long `if` condition?

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

PR Review: https://git.openjdk.org/jdk/pull/25688#pullrequestreview-3009483798
PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2200206398
PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2200225191
PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2200230806

From psadhukhan at openjdk.org  Fri Jul 11 10:16:28 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 11 Jul 2025 10:16:28 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v33]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Adjust offset for varying size imageicon

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/fcaeb2d2..103ef259

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=31-32

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

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

From psadhukhan at openjdk.org  Fri Jul 11 10:18:49 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 11 Jul 2025 10:18:49 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v30]
In-Reply-To: <vMhFPgTyeyhXWZSix12Btv-2lMIyTIaC_MVhuhSZQZs=.98bc24de-0832-4e66-8229-9a8b5b873dda@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <NhmSmPuexRUQv_3AYVfgYe0IR60vMG1z_3PYil68oac=.bbfe5f66-b07e-4299-b1d6-5c7db6217a45@github.com>
 <mc2ha9T7pUihQL4ugmYpyjTDfHl6ifrBwv_U-iCVTwA=.d01e78c2-9e9f-43c3-8617-5ae676c2e63e@github.com>
 <8CHi26jks_U-9jFq7DV9n1Yif2UpaZampCoTWCLxGG0=.95ff5b00-624b-4f8a-9386-0f8d692b799f@github.com>
 <jTfs-ve48402p333JuIyOnJjFoKqwNaUJa45_du_zu8=.5abcab29-f372-488e-853c-014ebc14dc7d@github.com>
 <QFetdv19Jeuk2nIJ5jG8Ju6dc8fJvADjILW9P0UN9Ts=.19ac45fa-5170-4cc2-bf11-2edd690273c3@github.com>
 <LQrOMe-aKNLvLvivFzUe2HyHCjz3J2TocWEchAwoQ7E=.d64bc1ee-3f77-40a7-976c-3f88a7fb68d6@github.com>
 <ihbtQ4a1zeDU1dgZ9UNHKacuK-9HB7Yxg73_yAVBNrI=.c5e3236b-e113-4670-b03d-02bb49083736@github.com>
 <55aysCZXurqsNGOCzpY51V5H6L-KTnrTHyNyZWR0D_E=.3ef2c49b-9323-4604-8bf0-75515c7b9097@github.com>
 <xBf5YM_yisonihPCwjVrd4Y4lLyRfu74MnM4t2bk2DU=.3d90e74d-4d60-466b-ae1d-a4659bf3425f@github.com>
 <vMhFPgTyeyhXWZSix12Btv-2lMIyTIaC_MV
 huhSZQZs=.98bc24de-0832-4e66-8229-9a8b5b873dda@github.com>
Message-ID: <g83JmTC-JemtEh4O9T6k2uq3ojPBRdAqdf6KrixGdr8=.16a87d1e-4e4d-49d2-87c3-b0f0e678d0f1@github.com>

On Fri, 4 Jul 2025 13:23:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> No, it still doesn't match the style and margins that we see in Windows File Explorer.
>> 
>> The latest fix doesn't change much, *the width of the menu hasn't changed*: you just move the elements around trying to fit more into the same space, which unavoidably reduces margins between elements.
>> 
>> The margin between the check mark / bullet and the icon should be larger, that popup menu in Windows File Explorer has 35 pixel-margin between the check mark and the icon, the latest version of the fix in this review has only 7 pixels.
>> 
>> The width allocated for the popup menu has to increase where both check marks / bullets and icons need to be rendered.
>
> Compare the screenshots of File Explorer and Swing to [own comment](https://github.com/openjdk/jdk/pull/23324#issuecomment-2705406453).
> 
> There's so much ?air? in File Explorer version of the popup menu. Yes, the location of the elements in Swing has changed since that time, but it can't match that in File Explorer.

Usually, BasicMenuItemUI/WindowsMenuItemUI paintMenuItem (https://github.com/openjdk/jdk/blob/445e5ecd98f41d4d625af5731f7b5d10c9225e49/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java#L652-L664) renders 5 column layout via `paintCheckIcon, paintIcon, paintText, paintAccText and paintArrowIcon `
where
 bullet/checkmark is rendered by `paintCheckIcon`
imageicon is rendered by `paintIcon`
menuitem text is rendered by `paintText`
accelerator text is rendered by `paintAccText `
and arrow icon for submneu is rendered by `paintArrowIcon `

This is usually the case for the rendering layout for non Windows L&F but for Windows L&F the paintIcon is rendered moot
because of presence of [VistaMenuItemCheckIconFactory] (https://github.com/openjdk/jdk/blob/445e5ecd98f41d4d625af5731f7b5d10c9225e49/src/java.desktop/share/classes/sun/swing/MenuItemLayoutHelper.java#L198-L205)

so paintCheckIcon only has to handle both bullet/checkmark AND imageicon
so the offset needs to be adjusted in the same method and is not separate column which is why the gap may not be as per standard or expected

@prrace As discussed offline, if imageicon is of different size then also the gap needs to be adjusted in that method making it more error prone..
Anyway I have tried some adjustment and latest PR looks like this

<img width="427" height="410" alt="image" src="https://github.com/user-attachments/assets/bd4aac91-91e1-4668-ab05-7f34acaf5af6" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2200316714

From jdv at openjdk.org  Fri Jul 11 10:18:53 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 11 Jul 2025 10:18:53 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v5]
In-Reply-To: <cDHvz_uvdt-uIQy2OF8eiebV85AcVsCLNcPf8OOSv8Q=.be12ce4a-05bd-4ff5-878e-53e98df1bc6d@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <SWwlsyVwR91GzaqjGg7r7DPBIVJ_tGNQIBD_wwxfVC4=.97d1d744-ca58-4fd7-8fc5-4a9175fa15cc@github.com>
 <cDHvz_uvdt-uIQy2OF8eiebV85AcVsCLNcPf8OOSv8Q=.be12ce4a-05bd-4ff5-878e-53e98df1bc6d@github.com>
Message-ID: <BMu1xyI3rXS45BF6uCSHLyovN04APKM7b07cyDKGc8I=.c173e2ea-59ed-4e16-86e6-42fa7a42bcb5@github.com>

On Fri, 11 Jul 2025 06:36:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Latest change looks good to me. I will run CI tests and update.

Applied this PR over latest mainline code and CI test is all green.

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

PR Comment: https://git.openjdk.org/jdk/pull/25264#issuecomment-3061621716

From azvegint at openjdk.org  Fri Jul 11 15:54:48 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 11 Jul 2025 15:54:48 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
Message-ID: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>

On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
One of the conformance tests fails on these hosts.

It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.

This changeset utilizes the Crtc and Output Randr APIs to change the display mode.

Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.

The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.

Testing looks good on VNC and local machines.

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

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/26268/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354415
  Stats: 354 lines in 3 files changed: 346 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26268/head:pull/26268

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

From honkar at openjdk.org  Fri Jul 11 17:52:40 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 11 Jul 2025 17:52:40 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <ipnU7QwBE81ju7q_7wGHI-TsFnwIgaYfyrZ9psJW17E=.80071b49-456e-40eb-abc8-0656fea48092@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
 <agZOSsq-V8T2lTUtGTPoRV6upUO6gPJmbGCg-DMDa20=.bc95a44f-47df-406c-ad38-6ea015b388e6@github.com>
 <xhtBYqXidGsodI4xt27FfeQX2R3ySGPAk-DOJ3sWx_0=.6ab958c9-3df7-4620-8184-2b7e65717314@github.com>
 <ipnU7QwBE81ju7q_7wGHI-TsFnwIgaYfyrZ9psJW17E=.80071b49-456e-40eb-abc8-0656fea48092@github.com>
Message-ID: <_1pB9sGaweUwZq9wYFSXbJUWW3ss07qy-7iHU-pG0L0=.113c408a-dde1-4267-bb9f-fbb6cbd2cf81@github.com>

On Fri, 11 Jul 2025 03:27:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> I don't think a new test is necessary. I updated the existing one.

Sounds good.

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

PR Comment: https://git.openjdk.org/jdk/pull/26170#issuecomment-3063200768

From honkar at openjdk.org  Fri Jul 11 17:52:42 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 11 Jul 2025 17:52:42 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered [v2]
In-Reply-To: <tQFLQ2UgBUW8ntAs6foEBN575El4JaVzhhjjS_8DffA=.4b44f63b-86d2-438d-a81c-e7971843b623@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
 <tQFLQ2UgBUW8ntAs6foEBN575El4JaVzhhjjS_8DffA=.4b44f63b-86d2-438d-a81c-e7971843b623@github.com>
Message-ID: <Ugn1JbTAzHMmlyxkq81LZ6xFMUkErtYe717HPeIT2gU=.85fd0f6f-5e9d-4ef2-b824-465c9cf62439@github.com>

On Fri, 11 Jul 2025 03:31:35 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
>> 
>> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make sure to test both numpad states

test/jdk/java/awt/event/KeyEvent/KeyCharTest/KeyCharTest.java line 87:

> 85:             robot.mouseRelease(MouseEvent.BUTTON1_DOWN_MASK);
> 86: 
> 87:             testKeyRange(robot, 0x20, 0x7E);

@azvegint 
Suppose an exception occurs when testing the first case  - 0x20 to 0x7E then the finally block with NumLock is executed irrespective of whether the NumLock was set for the next test case.

To avoid this we can add a separate try catch block for the 2 test ranges or another way is to check if NumLock is On/Off before setting and resetting it using
 `boolean isNumLockOn = toolkit.getLockingKeyState(KeyEvent.VK_NUM_LOCK);` (the 2nd option might be better).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26170#discussion_r2201432643

From duke at openjdk.org  Fri Jul 11 18:03:05 2025
From: duke at openjdk.org (Valery Semenchuk)
Date: Fri, 11 Jul 2025 18:03:05 GMT
Subject: RFR: 8360136: Support setting 'Figure Styles' while creating AWT Font
Message-ID: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>

Introducing to API constants, and implementation for controlling Figure Styles

Target font: *Inter*

Example screenshot 

![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)

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

Commit messages:
 - 8360136: introducing TextAttribute#PROPORTIONAL_FIGURES and TextAttribute#TABULAR_FIGURES for controlling Font figure styles

Changes: https://git.openjdk.org/jdk/pull/26144/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26144&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8360136
  Stats: 88 lines in 7 files changed: 84 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26144.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26144/head:pull/26144

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

From prr at openjdk.org  Fri Jul 11 18:14:51 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 11 Jul 2025 18:14:51 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v33]
In-Reply-To: <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>
Message-ID: <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>

On Fri, 11 Jul 2025 10:16:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust offset for varying size imageicon

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 932:

> 930:                                     skin.paintSkin(g, x + OFFSET, y + OFFSET, state);
> 931:                                 } else {
> 932:                                     if (icon.getIconHeight() > 16) {

Why does height > 16 matter ? How does it make icons align ?

Also - if that is satisfactorily answered then wouldn't the conditions here be more succinctly coded as 

                              if (icon == null || icon.getIconHeight() > 16) {
                                        skin.paintSkin(g, x + OFFSET, y + icon.getIconHeight() / 2, state);
                                     } else {
                                         skin.paintSkin(g, x + OFFSET, y + OFFSET, state);
                                     }

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 947:

> 945:                     } else {
> 946:                         icon.paintIcon(c, g, x + 6*OFFSET,
> 947:                                 y + OFFSET);

Where did the magic multiplier of 6 come from ?

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 248:

> 246:         paintIcon(g, lh, lr, holdc);
> 247: 
> 248:         boolean isWindows11OrLater = Integer.parseInt(System.getProperty("os.name")

Haven't we learned that it 'worked' on Windows 10 in an accidental and not ideal way?
ie. it didn't really work even there.
So do we even need to bother with this check ? Shouldn't Windows 10 do it the new way too ?

test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 31:

> 29:  *          JRadioButtonMenuItem and JCheckboxMenuItem
> 30:  *          is rendered with ImageIcon in WindowsLookAndFeel
> 31:  * @requires (os.family == "windows")

Can't we run this with all L&Fs on all platforms ? 
What about it would be so different in some other case ?

Also that last update for different sized icons isn't being tested - so can we vary the icon size in this test ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2201467717
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2201467227
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2201466381
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2201463390

From prr at openjdk.org  Fri Jul 11 18:22:47 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 11 Jul 2025 18:22:47 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out
In-Reply-To: <H8ACnUN9Ieki-Fmn5gccd4iTfjRxqbR-N-y5qnrxDqw=.ae7215cd-7e95-4c78-93ba-dfe244efb2c4@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
 <EnXD0-xl2uurJuu6uvgR5Lgc-GCssvLva19S8OTi1Q0=.18e687ef-a14f-4d6f-af11-d5236a232169@github.com>
 <H8ACnUN9Ieki-Fmn5gccd4iTfjRxqbR-N-y5qnrxDqw=.ae7215cd-7e95-4c78-93ba-dfe244efb2c4@github.com>
Message-ID: <7IbMmkSnfRGAqs1bvN5ftaJMK8DHncQtbof9V5-pfeM=.257ce973-a7c9-4502-b73c-6e914e9a7f50@github.com>

On Thu, 10 Jul 2025 21:47:09 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> To achieve good image printing quality, the printed image must be drawn using the printer's DPI or close to it if the DPI isn't known. The page is rendered in the following sequence "User Image" -> CPrinterGraphics -> SunGraphics2D -> CPrinterSurfaceData -> OSXSurfaceData -> "Native macOS User space".
> 
> CPrinterSurfaceData, OSXSurfaceData, and "Native macOS User space" from the rendering sequence are tightly coupled and contain data that is used in both native code and java, as well as CPrinterSurfaceData and OSXSurfaceData reflect the user space provided by macOS for rendering, including size and DPI, which is convenient and expected, and all the work on translations from the user space to the device space are performed automatically by macOS. Thus, I assumed that it is not reasonable to change anything in CPrinterSurfaceData and OSXSurfaceData.
> 
> To enable the user to determine the actual DPI of the printer, it remains possible to make changes to CPrinterGraphics or SunGraphics2D. I decided to add changes to SunGraphics2D because it is closer in the chain to rendering in macOS, and it also provides means for setting the necessary parameters through the existing public methods (setDevClip), and perform the reverse translation into the macOS user space in native code using scale methods specifically designed for this purpose. It is possible to add an additional constructor to SunGraphics2D that takes into account the necessary scaling, and thus avoid using setDevClip, but this changes the actual API of SunGraphics2D, which I tried to avoid.

Nothing else in the entire desktop module needs to directly set the device clip in this way.
Why is this case so unique ? 
I think there must be a better way that you've overlooked and it won't involve adding new code to SunGraphics2D

Also as I noted you are NOT using the actual DPI of the printer. You've just decided to use 300 instead of 72
Your hard-coded 300 gets used no matter what the real printer DPI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25489#discussion_r2201487078

From serb at openjdk.org  Fri Jul 11 18:35:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 11 Jul 2025 18:35:29 GMT
Subject: RFR: 8358468: Enhance code consistency: java.desktop/macos [v2]
In-Reply-To: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
References: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
Message-ID: <5zViysAQgPCSlPiwX0rYfNdBCzpf-y3yquFZd426xi4=.f8a708fc-0729-481d-a581-24a5e3894c19@github.com>

> This PR updates the last (!!) remaining platform-specific part of the java.desktop module: macos.
> The unix/windows were previously addressed in: https://github.com/openjdk/jdk/pull/24170 , https://github.com/openjdk/jdk/pull/24941 and https://github.com/openjdk/jdk/pull/25439.
> 
> Note: Unlike on other platforms, the initial change for macOS caused the "BadSerializationTest" to fail. This test relies on internal details of the Aqua Look & Feel that were previously exposed via serialized data (and already [fails](https://bugs.openjdk.org/browse/JDK-8277817) on other platforms). Adding the final modifier to the class changes its serialVersionUID, which triggered the failure even on macOS.
> To avoid this issue, I have reverted the changes to those internal classes for now, see https://github.com/openjdk/jdk/pull/25607/commits/ff7e64b6e38a1a809d434628f304e49408135697
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff -o d.txt && grep -E '^+|^-' d.txt | grep -vE '^+++|^---'
> 
> ====================================================
> 
> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected ...

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

 - Merge branch 'openjdk:master' into over_macos
 - Fix java/awt/dnd/BadSerializationTest/BadSerializationTest.java test
 - restore formatting
 - final in java.desktop/macos
 - override in java.desktop/macos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25607/files
  - new: https://git.openjdk.org/jdk/pull/25607/files/ff7e64b6..2ebaf02d

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

  Stats: 79677 lines in 2035 files changed: 50686 ins; 17126 del; 11865 mod
  Patch: https://git.openjdk.org/jdk/pull/25607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25607/head:pull/25607

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

From prr at openjdk.org  Fri Jul 11 18:53:48 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 11 Jul 2025 18:53:48 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v12]
In-Reply-To: <v90zuPcY6O_xsW3sPIyQpM7PXrvQyRxae3NygbwspuA=.47b79d5c-1461-47ff-a9c1-f107b6d415ce@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
 <i4BPuNcD8H3kyeVPAeAPaCvsBJbdG9NxVxVrzvfC58M=.78e4c633-fe9f-44f4-aea9-18483e532b1c@github.com>
 <v90zuPcY6O_xsW3sPIyQpM7PXrvQyRxae3NygbwspuA=.47b79d5c-1461-47ff-a9c1-f107b6d415ce@github.com>
Message-ID: <K6XplxZ0jffXV-19bVu3Zuy7scj6tfOUnyI60Oeh7FI=.e4d8df92-99c2-455d-849f-0ab59fd6c0a8@github.com>

On Tue, 8 Jul 2025 06:00:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > I think we need to have the "whole picture" tested to make sure everything does as we expect. It isn't so easy to tell even from looking at the source of ImageIcon. Then spec'ed so developers know what to expect. When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images Toolkit images are installed, even if they can't be used because the source isn't valid. They are "effectively" null, but not "actually" null. We should at least specify the null arg behaviours and try to say something about invalid image data. And as a result, I am now flipping to just documenting the setImage(null) NPE The protected method loadImage probably needs to say it too. Invalid image data, maybe we can cover that in a class level statement. Note: I'd like to see every constructor tested with both null and invalid image data.
> 
> I tested with null image/imagedata and invalid imagedata and it seems only these constructors throw NPE (current JDK) for null image (invalid image doesnt throw any exception)
> 
> ImageIcon(image, desc) ImageIcon(image) ImageIcon(byte[], desc) ImageIcon(byte[])
> 
> Current PR checks for null in ImageIcon(image) so it will not throw NPE but ImageIcon(byte[]) will still throw.. Should we handle those in separate PR and let this only be for setImage(null)?

You told me (off-line) that null URL also throws NPE and I see that too.

This class is a bit of a mess of accidental behaviours and scant documentation.

Let's document all the NPE behaviours and include a test that verifies it.

And invalid data like "new byte[0]" or null for a file name,  or pointing to something that isn't an image file, or an invalid URL .. etc .. results in an Image instance being present, but it will never be completed so can never be drawn.

I think we need a class level statement like
"If the image source parameter to a constructor is non-null, but does not reference valid accessible image data, no exceptions will be thrown but the image will be 'effectively' null, as it will have no dimensions and never be drawn, and
getImageLoadStatus() will report ERRORED" - you should verify that last part but I think it is right.

We probably should add the similar text on setImage().

We can also test the invalid image data cases too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3063379284

From duke at openjdk.org  Fri Jul 11 18:59:18 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 11 Jul 2025 18:59:18 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v6]
In-Reply-To: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
Message-ID: <kzNLoqMvrG0Gls8KnHlxy1KhQT-VGgLNs3cRphZuUuE=.b98c2075-65a4-4c8d-8c91-af0074a11b19@github.com>

> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
> 
> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
> 
> There are a cluster of four related PRs that share the GifComparison class in this PR.
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
> 
> This bug can be observed reading these gif animations:
> 
> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l

Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - 8357034: re-wrapping line breaks
 - 8356137, 8357034: add debug option to dump PNGs of frames
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
 - Merge branch 'master' into JDK-8357034
   
   # Conflicts:
   #	test/jdk/sun/awt/image/gif/GifBuilder.java
   #	test/jdk/sun/awt/image/gif/GifComparison.java
 - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
 - Merge branch 'master' into JDK-8357034
 - 8356320: Use new GifBuilder and remove ukraine-flag.gif
   
   This is an extension of work for this PR:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: adding copyright
 - 8356137: Adding GifBuilder to dynamically create test file
   
   This can be used by multiple gif tests in this directory.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: trivial javadoc update
 - 8356137: only inspect last frame of gif
   
   This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
 - ... and 22 more: https://git.openjdk.org/jdk/compare/a86dd56d...7c96ce19

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

Changes: https://git.openjdk.org/jdk/pull/25264/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25264&range=05
  Stats: 154 lines in 5 files changed: 119 ins; 4 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/25264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25264/head:pull/25264

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

From duke at openjdk.org  Fri Jul 11 18:59:19 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 11 Jul 2025 18:59:19 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v5]
In-Reply-To: <SWwlsyVwR91GzaqjGg7r7DPBIVJ_tGNQIBD_wwxfVC4=.97d1d744-ca58-4fd7-8fc5-4a9175fa15cc@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <SWwlsyVwR91GzaqjGg7r7DPBIVJ_tGNQIBD_wwxfVC4=.97d1d744-ca58-4fd7-8fc5-4a9175fa15cc@github.com>
Message-ID: <4Weh8tcUusUuBai1qJN5lNThFTwmJyowRyRe56BhwFo=.95d98006-68a0-47b0-bda2-4ce88bcce222@github.com>

On Thu, 10 Jul 2025 21:20:07 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
>> 
>> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
>> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
>> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
>> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
>  - Merge branch 'master' into JDK-8357034
>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: trivial javadoc update
>  - 8356137: only inspect last frame of gif
>    
>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
>  - 8356137: Adding copyright to GifComparison
>  - 8357034: fixing classname
>  - 8356320: trivial whitespace and comment changes
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/a41d3507...b8a8bf7d

This is merged with master, and I added an optional (commented out) argument to dump all the gif frames in a folder.

Also (as before) I tested this change with the known buggy gifs I collected, and this PR renders those correctly.

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

PR Comment: https://git.openjdk.org/jdk/pull/25264#issuecomment-3063394391

From prr at openjdk.org  Fri Jul 11 19:37:40 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 11 Jul 2025 19:37:40 GMT
Subject: RFR: 8360136: Support setting 'Figure Styles' while creating AWT
 Font
In-Reply-To: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
Message-ID: <fIVEavWTM30i_Bo0hNtTcLMWuULVCyA58X9s_1pI1bk=.c7c0c7ea-a068-4e54-969d-808f35c6b5d2@github.com>

On Sun, 6 Jul 2025 16:29:51 GMT, Valery Semenchuk <duke at openjdk.org> wrote:

> Introducing to API constants, and implementation for controlling Figure Styles
> 
> Target font: *Inter*
> 
> Example screenshot 
> 
> ![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)

Even if there's no easy way to verify it, there should be a test that at least uses these new values.

Also we need a CSR for this.

src/java.desktop/share/classes/java/awt/font/TextAttribute.java line 1122:

> 1120:      * <p>The constant value {@link #PROPORTIONAL_FIGURES_ON} is defined.
> 1121:      *
> 1122:      * <p>Conflicts with {@link #TABULAR_FIGURES}

True. So at an API level, should it be allowed to specify both at the same time ?
Perhaps instead the attribute should be called FIGURE_WIDTH and have values of PROPORTIONAL and TABULAR
But what about the other figure related 'standard' opentype features : lining and old style ?

https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko#lnum
https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko#onum

They are the same idea but it affects height / vertical positioning instead of width

So do we add FIGURE_HEIGHT too with values of LINING and OLDSTYLE ?

Or .. do we add 
FIGURE_STYLE and provide the combinations  like
TABULAR_LINING and PROPORTIONAL_OLDSTYLE ?

There'd be 16 values so I am not sure about that.
May be have the WIDTH and HEIGHT options and let people select the pairs they want.
Also it means if they 'don't care" about one or the other they can just not set it instead of thinking.

src/java.desktop/share/classes/java/awt/font/TextAttribute.java line 1130:

> 1128: 
> 1129:     /**
> 1130:      * Request to enable proprotional figures.

typo : proprotional -> proportional

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

PR Review: https://git.openjdk.org/jdk/pull/26144#pullrequestreview-3011621639
PR Review Comment: https://git.openjdk.org/jdk/pull/26144#discussion_r2201679599
PR Review Comment: https://git.openjdk.org/jdk/pull/26144#discussion_r2201602266

From prr at openjdk.org  Fri Jul 11 19:43:40 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 11 Jul 2025 19:43:40 GMT
Subject: RFR: 8360136: Support setting 'Figure Styles' while creating AWT
 Font
In-Reply-To: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
Message-ID: <foHud3SBXwVBkUVmYRoKO5ybxJUGpYgs3938DCG4vR4=.77d6fce3-8540-4fec-9c8c-78725182d1a4@github.com>

On Sun, 6 Jul 2025 16:29:51 GMT, Valery Semenchuk <duke at openjdk.org> wrote:

> Introducing to API constants, and implementation for controlling Figure Styles
> 
> Target font: *Inter*
> 
> Example screenshot 
> 
> ![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)

I have changed the bug summary so you will need to change the PR summary to match -
8360136: RFE: Add TextAttributes for OpenType font figure style features

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

PR Comment: https://git.openjdk.org/jdk/pull/26144#issuecomment-3063561018

From prr at openjdk.org  Fri Jul 11 20:07:46 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 11 Jul 2025 20:07:46 GMT
Subject: RFR: 6955128: Spec for
 javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate
 wording [v5]
In-Reply-To: <XNsAGPGxzliTolBRY3Pk200pTpjAV2iZHMsmh0fJM3Y=.cf2ba615-5cb2-4f26-9d44-0f84e41968d2@github.com>
References: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
 <XNsAGPGxzliTolBRY3Pk200pTpjAV2iZHMsmh0fJM3Y=.cf2ba615-5cb2-4f26-9d44-0f84e41968d2@github.com>
Message-ID: <1MWOjDq1XQM-LURJhlplCg4NL2CnbUhEcqpDT6HCLYU=.38ac2572-f09a-4435-aba7-95eb4224e066@github.com>

On Tue, 8 Jul 2025 03:20:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named".
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid latin

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25850#pullrequestreview-3011825751

From prr at openjdk.org  Fri Jul 11 20:13:02 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 11 Jul 2025 20:13:02 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v15]
In-Reply-To: <rwkuHsqWQfZZAFxpylJZHZnPcWHJ1f0O2KimS7WbGxw=.2a3d404c-3000-4943-a3d9-dd619529aebc@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <xdbhtBgikqvegs36jK5HQykyZPSHJ_hhB5xDCg_dqxw=.97a8c90f-4b87-406a-b0a7-1c73722f1e26@github.com>
 <Idbkr_1O6El_xQd5NqPpe4wvCrnN7ILYcH7lK2nx-3w=.9a87e19e-f975-4820-8b89-c066c233301c@github.com>
 <rwkuHsqWQfZZAFxpylJZHZnPcWHJ1f0O2KimS7WbGxw=.2a3d404c-3000-4943-a3d9-dd619529aebc@github.com>
Message-ID: <uXdIKOC0Dk1TyKoKgkcCIUAKbzK7DQPtGCfHADhKOaM=.8ab91987-47da-441a-92a0-eb46394b8e60@github.com>

On Thu, 8 May 2025 21:22:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Robot.java line 138:
>> 
>>> 136:      * Default 2 pixel step length for mouse {@code glide}.
>>> 137:      */
>>> 138:     public static final int DEFAULT_STEP_LENGTH = 2;
>> 
>> Do we want to make the `DEFAULT_DELAY` and `DEFAULT_STEP_LENGTH` configurable?
>
> "glide  has over-rides step length"
> 
> Sorry, that text was not clear. What I mean is that glide(..) accepts delay and step parameters, and so at least in that case you can over-ride with your preferred values.
> 
> Other than that, it isn't configurable in the ExtendedRobot, so the need isn't clear.
> 
> Even so, we could do this but whether now or later, but in either case,
> we ought to think now as to what it would look like so it can be compatibly added.
> 
> In ExtendedRobot the equivalent fields are private but here they are public.
> Tests might start to use them directly. I'm not sure what for, but they might.
> But if it is configurable tests probably should instead  call a getter() for the currently set delay/step.
> 
> Then all the methods that now mention DEFAULT_ would probably need to mention something like
> getMouseDelay() and getStepLength() instead.
> 
> So it may be better to do it now ? Thoughts ?

@alisenchung did you see the above ? 
Looks like email for it may not have been generated because I *edited* an old comment rather than adding a new one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2201751507

From aturbanov at openjdk.org  Fri Jul 11 20:14:51 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 11 Jul 2025 20:14:51 GMT
Subject: RFR: 8362067: Remove unnecessary List.contains key from
 SpringLayout.Constraints.pushConstraint
Message-ID: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>

There is no need to call `List.contains` before `List.remove` call.
`history` is an either `horizontalHistory` or `verticalHistory`. Both of them are ArrayList's.

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

Commit messages:
 - [PATCH] Remove unnecessary List.contains key from SpringLayout.Constraints.pushConstraint

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

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

From azvegint at openjdk.org  Fri Jul 11 20:19:18 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 11 Jul 2025 20:19:18 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered [v3]
In-Reply-To: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
Message-ID: <8jiqfUasoVrEx-e3ExhQk0QyeLBO-Umcddr6QRj9MqU=.54972e59-53c1-45dd-8390-6ddd451ef2c9@github.com>

> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
> 
> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.

Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:

  wasNumpadPressed check added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26170/files
  - new: https://git.openjdk.org/jdk/pull/26170/files/db92a1fb..e25f63da

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

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

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

From azvegint at openjdk.org  Fri Jul 11 20:19:18 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 11 Jul 2025 20:19:18 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered [v2]
In-Reply-To: <Ugn1JbTAzHMmlyxkq81LZ6xFMUkErtYe717HPeIT2gU=.85fd0f6f-5e9d-4ef2-b824-465c9cf62439@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
 <tQFLQ2UgBUW8ntAs6foEBN575El4JaVzhhjjS_8DffA=.4b44f63b-86d2-438d-a81c-e7971843b623@github.com>
 <Ugn1JbTAzHMmlyxkq81LZ6xFMUkErtYe717HPeIT2gU=.85fd0f6f-5e9d-4ef2-b824-465c9cf62439@github.com>
Message-ID: <vl8E8xQm1407_ueSM3TFWPQMhoGZYvYU_uAoNWqnbcM=.f81000fe-3177-4c93-902b-fcedcb6c5a05@github.com>

On Fri, 11 Jul 2025 17:44:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Suppose an exception occurs when testing the first case - 0x20 to 0x7E then the finally block with NumLock is executed irrespective of whether the NumLock was set for the next test case.

This is not how it actually works. The try-catch-finally(with NumLock press/release) block executes on the main thread, and the exception is thrown on the EDT (line 52).  The jtreg test failure is due to the exception on the EDT.

It checks all the test cases with the NumLock key both on and off.

For example, apply the following patch to the test to make it always fail within the first key range:


- if (value != null && e.getKeyChar() != value) {
+ if (value != null && e.getKeyChar() != value || e.getKeyCode() == 0x21) {

Observe the exception stack trace from EDT

java.lang.RuntimeException: Wrong KeyChar on KEY_RELEASED Page Up
	at KeyCharTest.keyReleased(KeyCharTest.java:53)
	at java.desktop/java.awt.Component.processKeyEvent(Component.java:6537)
	at java.desktop/java.awt.Component.processEvent(Component.java:6353)
	at java.desktop/java.awt.Container.processEvent(Container.java:2260)
	at java.desktop/java.awt.Window.processEvent(Window.java:1966)
	at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4958)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2318)
	at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2671)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4790)
	at java.desktop/java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1829)
	at java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:874)
	at java.desktop/java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1136)
	at java.desktop/java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:1011)
	at java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:839)
	at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4839)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2318)
	at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2671)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4790)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:725)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:702)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)


However, I updated the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26170#discussion_r2201760433

From honkar at openjdk.org  Fri Jul 11 20:49:38 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 11 Jul 2025 20:49:38 GMT
Subject: RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered [v3]
In-Reply-To: <8jiqfUasoVrEx-e3ExhQk0QyeLBO-Umcddr6QRj9MqU=.54972e59-53c1-45dd-8390-6ddd451ef2c9@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
 <8jiqfUasoVrEx-e3ExhQk0QyeLBO-Umcddr6QRj9MqU=.54972e59-53c1-45dd-8390-6ddd451ef2c9@github.com>
Message-ID: <zmH3IwarTr7zbhnHNUqZQimrO7KoVC0X11rgV7PrrDs=.366fe212-b008-4791-aa25-41238e7f81a3@github.com>

On Fri, 11 Jul 2025 20:19:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
>> 
>> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wasNumpadPressed check added

Tested the fix on Ubuntu 24.04  (with `-Dawt.robot.screenshotMethod=dbusRemoteDesktop`) and Ubuntu 25.04, fix works as expected.

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26170#pullrequestreview-3011935266

From aivanov at openjdk.org  Fri Jul 11 21:00:47 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 11 Jul 2025 21:00:47 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v33]
In-Reply-To: <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>
 <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
Message-ID: <tFsIIRvvF79IkHwjB1bTSVND4rSFBWtjJh17s0h6-xg=.c43288a4-2d7f-4072-a327-7323c76b63bd@github.com>

On Fri, 11 Jul 2025 18:05:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust offset for varying size imageicon
>
> test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 31:
> 
>> 29:  *          JRadioButtonMenuItem and JCheckboxMenuItem
>> 30:  *          is rendered with ImageIcon in WindowsLookAndFeel
>> 31:  * @requires (os.family == "windows")
> 
> Can't we run this with all L&Fs on all platforms ? 
> What about it would be so different in some other case ?
> 
> Also that last update for different sized icons isn't being tested - so can we vary the icon size in this test ?

Should we run this test for all L&Fs?

So far, Windows L&F was unique in the way that it combined both check marks / bullets and icons. If we implement it the new way so that all the check marks / bullets and menu icons align, the menu behaviour in Windows L&F will be the same as that in Metal and Nimbus at least.

`javax/swing/JMenuItem/RightLeftOrientation.java` tests a similar scenario. If the behaviour of Windows L&F is the same as in other L&F, we may just add this bug id to an existing test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2201835865

From aivanov at openjdk.org  Fri Jul 11 21:12:48 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 11 Jul 2025 21:12:48 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v33]
In-Reply-To: <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>
 <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
Message-ID: <icKQrBbjRkYWpZ6_bvPYUzAxHIsH-a4iQP510lHj6TU=.72699793-dacc-4cbc-8bc6-4fec98745f4e@github.com>

On Fri, 11 Jul 2025 18:09:05 GMT, Phil Race <prr at openjdk.org> wrote:

> Why does height > 16 matter ? How does it make icons align ?

Perhaps, it's because standard Windows menu icons are 16?16; if the icon is larger something may need adjusting.

Yet I don't know the answer?

> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java line 248:
> 
>> 246:         paintIcon(g, lh, lr, holdc);
>> 247: 
>> 248:         boolean isWindows11OrLater = Integer.parseInt(System.getProperty("os.name")
> 
> Haven't we learned that it 'worked' on Windows 10 in an accidental and not ideal way?
> ie. it didn't really work even there.
> So do we even need to bother with this check ? Shouldn't Windows 10 do it the new way too ?

I think it worked on Windows 10 (as well as previous versions of Windows) by design, that is Windows L&F was implemented to mimic what's was common during Windows XP era which held with Windows 10 too. Yet Windows 11 changed its menu design, therefore the existing design stopped working.

> So do we even need to bother with this check ? Shouldn't Windows 10 do it the new way too ?

I'd rather go this way. Let Swing menus look consistently in Windows 10 and 11. [I suggested doing this way](https://github.com/openjdk/jdk/pull/23324#discussion_r1949596849) in February.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2201870931
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2201866149

From aivanov at openjdk.org  Fri Jul 11 21:16:40 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 11 Jul 2025 21:16:40 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts
In-Reply-To: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
Message-ID: <ndwDmZRKWph9a67bOUG9kSDNEQqgBOOgjmGiP3Rim0g=.2a6f7afc-bfd6-46a8-8a1a-a5c15550bfe1@github.com>

On Mon, 9 Jun 2025 02:36:44 GMT, Jeremy Wood <duke at openjdk.org> wrote:

> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
> 
> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)

Client tests are green.

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

PR Comment: https://git.openjdk.org/jdk/pull/25688#issuecomment-3063855833

From duke at openjdk.org  Fri Jul 11 22:58:55 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 11 Jul 2025 22:58:55 GMT
Subject: RFR: 8351913: ToolkitImage renders some gifs wrong [v7]
In-Reply-To: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
References: <74IJiA4t9MAOiGPCGuls0-KbIfGg9D2bNUXPapOx0Zs=.4cdf9b89-4007-4727-a07e-ac4eae84134e@github.com>
Message-ID: <DLVak6S9t8WsxoA7DlAO_NF12W0zWODcktvuI8eHeMU=.0eb73973-9876-4d16-b99d-ce7579a3223a@github.com>

> I do not have much background in LZW compression or in C, but I'm reasonably confident this resolves the problem I'm observing. It looks like the GifImageDecoder was not always correctly handling compression codes after the table reached its limit of ~4096. If anyone has suggestions for improvements I'm happy to make adjustments.
> 
> Luckily while debugging this: I was able to compare the flawed implementation (GifImageDecoder) with ImageIO's implementation (GIFImageReader) to help identify how the suffix/prefix tables are supposed to work.
> 
> ImageIO's implementation may have suffered a similar bug (maybe https://bugs.openjdk.org/browse/JDK-7131823 ?), and that appears to have been backported.
> 
> There are a cluster of four related PRs that share the GifComparison class in this PR.
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271) (this one)
> 
> This bug can be observed reading these gif animations:
> https://pixabay.com/gifs/pattern-mandela-geometric-loading-20162/
> https://pixabay.com/gifs/colourful-paint-spiral-pattern-20276/
> https://pixabay.com/gifs/dance-party-dancer-dancing-girl-19993/
> https://pixabay.com/gifs/spiral-orbit-colourful-pattern-20278/
> https://pixabay.com/gifs/flower-smiley-happy-yellow-bright-11997/
> https://pixabay.com/gifs/ghost-spooky-halloween-horror-20223/
> https://pixabay.com/gifs/fish-tadpole-sperm-decorative-20078/
> https://pixabay.com/gifs/cat-kitten-black-cats-sleep-nap-20104/
> https://giphy.com/gifs/party-gzhreEYEFrEYw
> https://giphy.com/gifs/hello-happy-birthday-all-xRVUlSCqTTZRLMdUiC
> https://giphy.com/gifs/GpANv0ZGOo973DNPyg
> https://giphy.com/gifs/pinatafarmsapp-birthday-happy-pinata-farms-rrmf3fICPZWg1MMXOW
> https://pixabay.com/gifs/stars-twinkle-sky-universe-cosmos-13910/
> https://pixabay.com/gifs/laundry-washing-clean-clothes-18875/
> https://giphy.com/gifs/cat-white-mikitti-VItynXR1BzF5z0aTM7
> https://giphy.com/gifs/love-good-morning-cute-sTuKV3kHCkuc1hzd5C
> https://giphy.com/gifs/tv2norge-dance-celebration-birthday-duNowzaVje6Di3hnOu
> https://tenor.com/view/hasher-sticker-gif-24531859
> https://giphy.com/gifs/animanias-emoji-mickey-mouse-minnie-BeiTtDrExJZsoHzglJ
> https://giphy.com/gifs/morning-good-gm-dvwk9tqWYN8Wn2s4yn
> https://giphy.com/gifs/memoriachilena-familia-memoria-chilena-patrimonio-cultural-comn-7rRmOg13aXImUOEhO7
> https://giphy.com/gifs/thegoodpla...

Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - 8351913: re-wrapping line breaks
 - Merge branch 'master' into JDK-8351913
   
   # Conflicts:
   #	test/jdk/sun/awt/image/gif/GifComparison.java
 - Merge branch 'master' into JDK-8351913
 - 8356137: Adding copyright to GifComparison
 - 8356320: trivial whitespace and comment changes
 - Merge branch 'master' into JDK-8351913
 - Merge branch 'master' of https://github.com/mickleness/jdk
 - 8351913: renaming class, rewording comment
   
   There's a cluster of 4 related gif tickets I intend to put in this /gif/ directory. I want to better clarify exactly what this test focuses on.
 - GifComparison: fixing error message
 - GifComparison: code cleanup
 - ... and 23 more: https://git.openjdk.org/jdk/compare/a86dd56d...166a998b

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

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

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

From duke at openjdk.org  Fri Jul 11 23:01:24 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 11 Jul 2025 23:01:24 GMT
Subject: RFR: 8356320: GifImageDecoder can produce wrong image when GCE
 changes transparent pixel index [v3]
In-Reply-To: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
References: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
Message-ID: <_PbpWiu5Ggo6nKOlpaJC0mBZl9vxDQln5Z-2q67O9iU=.26c8458c-813e-43b5-8a34-0b76b4dca6fe@github.com>

> When a gif frame's disposal code is DISPOSAL_BGCOLOR and we're maintaining a saved image: we have to flood-fill the frame's bounds. And if the transparent pixel index changes across frames: we could sometimes flood fill the wrong value, resulting in an opaque rectangle in the output image.
> 
> There are a cluster of four related PRs that share the GifComparison class in this PR.
> 
> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) (this one)
> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
> 
> The test in this PR required [8356137's PR](https://github.com/openjdk/jdk/pull/25044) to pass.
> 
> This bug can be observed reading this gif animation:
> https://tenor.com/view/fnf-free-download-fnf-free-download-fnf-fd-cyan-gif-15334412416964826224

Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' into JDK-8356320
   
   # Conflicts:
   #	test/jdk/sun/awt/image/gif/GifBuilder.java
   #	test/jdk/sun/awt/image/gif/GifComparison.java
 - Merge branch 'master' into JDK-8356320
 - 8356320: Use new GifBuilder and remove leo.gif
   
   This is an extension of work for this PR:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: adding copyright
 - 8356137: Adding GifBuilder to dynamically create test file
   
   This can be used by multiple gif tests in this directory.
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
 - 8356137: trivial javadoc update
 - 8356137: only inspect last frame of gif
   
   This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
 - 8356137: Adding copyright to GifComparison
 - 8356320: trivial whitespace and comment changes
 - Merge branch 'master' into JDK-8356320
 - ... and 21 more: https://git.openjdk.org/jdk/compare/a86dd56d...3deeb497

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

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

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

From duke at openjdk.org  Fri Jul 11 23:01:24 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Fri, 11 Jul 2025 23:01:24 GMT
Subject: RFR: 8356320: GifImageDecoder can produce wrong image when GCE
 changes transparent pixel index [v2]
In-Reply-To: <x3Jl4XnOdn_hRw1jwwM3bZQh1E8Brbt4B-HRF1pfI38=.b067544e-c19d-45eb-8085-ccf843f5cc46@github.com>
References: <3RTnzdT8-vrt_0nq19kYPZh0-zexouw2d3FjxNY2R5Q=.53abc5a2-b5d9-4386-9c8d-36f2677dfccc@github.com>
 <x3Jl4XnOdn_hRw1jwwM3bZQh1E8Brbt4B-HRF1pfI38=.b067544e-c19d-45eb-8085-ccf843f5cc46@github.com>
Message-ID: <D-ENOLbiNZfnAFqwa_g8r2QaaisgdV8rEvwcf0Rmgnc=.fccc1145-69ff-4f3b-b2b5-ff2dce4dd6cb@github.com>

On Thu, 15 May 2025 00:33:19 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> When a gif frame's disposal code is DISPOSAL_BGCOLOR and we're maintaining a saved image: we have to flood-fill the frame's bounds. And if the transparent pixel index changes across frames: we could sometimes flood fill the wrong value, resulting in an opaque rectangle in the output image.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076) (this one)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> The test in this PR required [8356137's PR](https://github.com/openjdk/jdk/pull/25044) to pass.
>> 
>> This bug can be observed reading this gif animation:
>> https://tenor.com/view/fnf-free-download-fnf-free-download-fnf-fd-cyan-gif-15334412416964826224
>
> Jeremy Wood has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - 8356320: fixing copy & paste typo
>  - GifComparison: fixing error message
>  - GifComparison: code cleanup
>  - 8356320: change package to access GifComparison
>  - GifComparison: adding common helper class for gif bugs

I merged with master and confirmed the unit test passes and the original sample gif (fnf-free-download in PR description) passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25076#issuecomment-3063986572

From duke at openjdk.org  Sat Jul 12 03:34:08 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Sat, 12 Jul 2025 03:34:08 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v2]
In-Reply-To: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
Message-ID: <vn6c-yzgaGPwO65YigW34Wv-Wsts3ywMOF3CaDT2Ztg=.a713ca49-498b-4ce8-99b1-ff87e4b19fba@github.com>

> There were a few action bindings available in JPasswordFields in Aqua that let you identify the boundaries of words.
> 
> This came to my attention while looking at the related work https://github.com/openjdk/jdk/pull/25443 . In that PR we said we should iterate across all available L&Fs, so this PR copies that same approach. (The original complaint only focused on Aqua, though.)

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

 - 8358813: putting the actions in a TreeSet
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25688#discussion_r2200230806
 - 8358813: make input map types a static constant
   
   This is in response to:
   https://github.com/openjdk/jdk/pull/25688#discussion_r2200225191
 - Merge branch 'master' into JDK-8358813
 - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - 8358813: remove more bindings for JPasswordFields in Aqua

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25688/files
  - new: https://git.openjdk.org/jdk/pull/25688/files/e5acb921..6b497a71

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

  Stats: 138808 lines in 2708 files changed: 82801 ins; 34436 del; 21571 mod
  Patch: https://git.openjdk.org/jdk/pull/25688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25688/head:pull/25688

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

From duke at openjdk.org  Sat Jul 12 03:34:09 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Sat, 12 Jul 2025 03:34:09 GMT
Subject: RFR: 8358813: JPasswordField identifies spaces in password via
 delete shortcuts [v2]
In-Reply-To: <5TRU7CRYnFpgQ3LaA1DBM6017CC8Lp-G8craQZcr9xk=.d15840a3-f549-4be9-862a-9f1a88b1614b@github.com>
References: <vqqZB5NpVXwR0Y1P8vVj7x8covx3h2XSK-Os5TMjErA=.9efcdc01-3a05-45b2-930c-b71473abcce0@github.com>
 <5TRU7CRYnFpgQ3LaA1DBM6017CC8Lp-G8craQZcr9xk=.d15840a3-f549-4be9-862a-9f1a88b1614b@github.com>
Message-ID: <lq8O9lX4bmTFJV7WioSPAgimRi99vTzBNhjI83crmYw=.f6aa6fac-d8af-46cd-be24-27e3288ac6bf@github.com>

On Fri, 11 Jul 2025 09:25:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - 8358813: putting the actions in a TreeSet
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200230806
>>  - 8358813: make input map types a static constant
>>    
>>    This is in response to:
>>    https://github.com/openjdk/jdk/pull/25688#discussion_r2200225191
>>  - Merge branch 'master' into JDK-8358813
>>  - Update test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - 8358813: remove more bindings for JPasswordFields in Aqua
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java line 1:
> 
>> 1: /*
> 
> Please, update the copyright year.

This is no longer necessary after merging with master ( see 2bff8e0a1382f8820bc2479af87e45dc6b74cdb5 )

> test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 76:
> 
>> 74:                 JComponent.WHEN_FOCUSED,
>> 75:                 JComponent.WHEN_ANCESTOR_OF_FOCUSED_COMPONENT
>> 76:         }) {
> 
> The array with input map types could be a static constant just above `runTest` method.

OK, this is updated.

> test/jdk/javax/swing/JPasswordField/PasswordFieldInputMapWordTest.java line 93:
> 
>> 91:                         actionBinding == DefaultEditorKit.nextWordAction ||
>> 92:                         actionBinding == DefaultEditorKit.selectionPreviousWordAction ||
>> 93:                         actionBinding == DefaultEditorKit.selectionNextWordAction ) {
> 
> Does it make sense to put the actions in a list or array? Then `listOfActions.contains(actionBinding)` instead of this long `if` condition?

I don't have a preference. I pushed an update that wraps them in a TreeSet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2202281546
PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2202281420
PR Review Comment: https://git.openjdk.org/jdk/pull/25688#discussion_r2202281674

From serb at openjdk.org  Sat Jul 12 04:10:44 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 12 Jul 2025 04:10:44 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
Message-ID: <PtQJVYys5CxI9X0LYR5UkIlW0tdRoyA07UnDHPFbAE8=.5be231f1-75aa-4e19-9187-18bd55312c19@github.com>

On Fri, 11 Jul 2025 15:47:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>except for some VNC-configured hosts
what VNC server is used on that hosts?

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

PR Comment: https://git.openjdk.org/jdk/pull/26268#issuecomment-3064631835

From duke at openjdk.org  Sat Jul 12 07:46:17 2025
From: duke at openjdk.org (Valery Semenchuk)
Date: Sat, 12 Jul 2025 07:46:17 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features [v2]
In-Reply-To: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
Message-ID: <2wtH9yzh-z77a2X0-Lv1wBBlQk7SwZhcLCaKTK_-FUU=.ceeb4cb1-68c6-4009-a8ad-b09678c8e047@github.com>

> Introducing to API constants, and implementation for controlling Figure Styles
> 
> Target font: *Inter*
> 
> Example screenshot 
> 
> ![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)

Valery Semenchuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8360136: introducing TextAttribute#PROPORTIONAL_FIGURES and TextAttribute#TABULAR_FIGURES for controlling Font figure styles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26144/files
  - new: https://git.openjdk.org/jdk/pull/26144/files/a3b6912e..0bb773d0

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

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

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

From duke at openjdk.org  Sat Jul 12 07:49:39 2025
From: duke at openjdk.org (Valery Semenchuk)
Date: Sat, 12 Jul 2025 07:49:39 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features [v2]
In-Reply-To: <2wtH9yzh-z77a2X0-Lv1wBBlQk7SwZhcLCaKTK_-FUU=.ceeb4cb1-68c6-4009-a8ad-b09678c8e047@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
 <2wtH9yzh-z77a2X0-Lv1wBBlQk7SwZhcLCaKTK_-FUU=.ceeb4cb1-68c6-4009-a8ad-b09678c8e047@github.com>
Message-ID: <AmSJyVF1G5KSGmEKbU5b-0ToJwExct2Z_ldQnqndVEI=.05223bff-e6e6-4cc2-9a36-436beda3077e@github.com>

On Sat, 12 Jul 2025 07:46:17 GMT, Valery Semenchuk <duke at openjdk.org> wrote:

>> Introducing to API constants, and implementation for controlling Figure Styles
>> 
>> Target font: *Inter*
>> 
>> Example screenshot 
>> 
>> ![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)
>
> Valery Semenchuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8360136: introducing TextAttribute#PROPORTIONAL_FIGURES and TextAttribute#TABULAR_FIGURES for controlling Font figure styles

Sure. My mistake

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

PR Comment: https://git.openjdk.org/jdk/pull/26144#issuecomment-3064899111

From duke at openjdk.org  Sat Jul 12 08:12:41 2025
From: duke at openjdk.org (Valery Semenchuk)
Date: Sat, 12 Jul 2025 08:12:41 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features [v2]
In-Reply-To: <fIVEavWTM30i_Bo0hNtTcLMWuULVCyA58X9s_1pI1bk=.c7c0c7ea-a068-4e54-969d-808f35c6b5d2@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
 <fIVEavWTM30i_Bo0hNtTcLMWuULVCyA58X9s_1pI1bk=.c7c0c7ea-a068-4e54-969d-808f35c6b5d2@github.com>
Message-ID: <mhYF8JpSwQlRXQ8Dr-hn6LO-TbiJYxx4vhltWjY-SoI=.bdcc98c9-545c-4848-b8fb-541d1f52811b@github.com>

On Fri, 11 Jul 2025 19:33:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> Valery Semenchuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8360136: introducing TextAttribute#PROPORTIONAL_FIGURES and TextAttribute#TABULAR_FIGURES for controlling Font figure styles
>
> src/java.desktop/share/classes/java/awt/font/TextAttribute.java line 1122:
> 
>> 1120:      * <p>The constant value {@link #PROPORTIONAL_FIGURES_ON} is defined.
>> 1121:      *
>> 1122:      * <p>Conflicts with {@link #TABULAR_FIGURES}
> 
> True. So at an API level, should it be allowed to specify both at the same time ?
> Perhaps instead the attribute should be called FIGURE_WIDTH and have values of PROPORTIONAL and TABULAR
> But what about the other figure related 'standard' opentype features : lining and old style ?
> 
> https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko#lnum
> https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko#onum
> 
> They are the same idea but it affects height / vertical positioning instead of width
> 
> So do we add FIGURE_HEIGHT too with values of LINING and OLDSTYLE ?
> 
> Or .. do we add 
> FIGURE_STYLE and provide the combinations  like
> TABULAR_LINING and PROPORTIONAL_OLDSTYLE ?
> 
> There'd be 16 values so I am not sure about that.
> May be have the WIDTH and HEIGHT options and let people select the pairs they want.
> Also it means if they 'don't care" about one or the other they can just not set it instead of thinking.

Hello. Main idea - is to provide access to control this features in a simple way, without modification native & java too much.

Conflict described only in JavaDoc since - I don't want add special throws inside `Font` constructor with this options.

About what you say. Yes - I thought about that, but it's too big change. 

For example - will be nice move control hb features control from C++ code to Java. For now it's controlled by flags, and not flexable. 

What do you think about this api:


// internal api in sun.font

// enum for better control values, since there no sense give access to set 3,4,5+ values
public enum EFigureWidth {
    // unset? unknown? undefined?
    UNSET,
    PROPORTIONAL_FIGURES, // pnum=1
    TABULAR_FIGURES       // tnum=1
}

// public api
public class TextAttribute {

    public static final TextAttribute FIGURE_WIDTH = new TextAttribute("figure-width");

    public static final Object FIGURE_WIDTH_UNSET = EFigureWidth.UNSET;
    
    public static final Object FIGURE_WIDTH_TABULAR = EFigureWidth.TABULAR_FIGURES;

    public static final Object FIGURE_WIDTH_PROPORTIONAL = EFigureWidth.PROPORTIONAL_FIGURES;

    // same for figure height
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26144#discussion_r2202427915

From duke at openjdk.org  Sat Jul 12 08:21:23 2025
From: duke at openjdk.org (Valery Semenchuk)
Date: Sat, 12 Jul 2025 08:21:23 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features [v3]
In-Reply-To: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
Message-ID: <OZQyntt4IjrxJGh2DoskSQYyTIyaNtp0bzEJH7wBWvs=.d21e8b10-7c5a-4dbf-8904-6f6a8e5b6529@github.com>

> Introducing to API constants, and implementation for controlling Figure Styles
> 
> Target font: *Inter*
> 
> Example screenshot 
> 
> ![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)

Valery Semenchuk has updated the pull request incrementally with one additional commit since the last revision:

  fix wrong import reformat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26144/files
  - new: https://git.openjdk.org/jdk/pull/26144/files/0bb773d0..7767aaa0

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

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

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

From azvegint at openjdk.org  Sat Jul 12 09:42:38 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Sat, 12 Jul 2025 09:42:38 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <PtQJVYys5CxI9X0LYR5UkIlW0tdRoyA07UnDHPFbAE8=.5be231f1-75aa-4e19-9187-18bd55312c19@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
 <PtQJVYys5CxI9X0LYR5UkIlW0tdRoyA07UnDHPFbAE8=.5be231f1-75aa-4e19-9187-18bd55312c19@github.com>
Message-ID: <qJmTbuiHGsVwiWg6PvXBJ0tcV94JYvTBgIAvpWVxihI=.777515e0-bcba-4729-b88f-4748fa3348c1@github.com>

On Sat, 12 Jul 2025 04:08:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > except for some VNC-configured hosts
>
> what VNC server is used on that hosts?

It is a TigerVNC with a virtual Xtigervnc server (no physical display is connected).

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

PR Comment: https://git.openjdk.org/jdk/pull/26268#issuecomment-3064998207

From duke at openjdk.org  Sat Jul 12 11:15:39 2025
From: duke at openjdk.org (Valery Semenchuk)
Date: Sat, 12 Jul 2025 11:15:39 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features
In-Reply-To: <foHud3SBXwVBkUVmYRoKO5ybxJUGpYgs3938DCG4vR4=.77d6fce3-8540-4fec-9c8c-78725182d1a4@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
 <foHud3SBXwVBkUVmYRoKO5ybxJUGpYgs3938DCG4vR4=.77d6fce3-8540-4fec-9c8c-78725182d1a4@github.com>
Message-ID: <pbR1Da7KATa7bQ2hVoGR3dm5QIdqzUgdzPfA1IFYmlU=.4b1910ee-7b7d-4ecd-b239-6c896c79dcc4@github.com>

On Fri, 11 Jul 2025 19:40:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> Introducing to API constants, and implementation for controlling Figure Styles
>> 
>> Target font: *Inter*
>> 
>> Example screenshot 
>> 
>> ![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)
>
> I have changed the bug summary so you will need to change the PR summary to match -
> 8360136: RFE: Add TextAttributes for OpenType font figure style features

@prrace about tests. I can write test with calculating width/height with font which is support it, and validate. Primitive one.

For example
 * at start - need install font with this features. For example `Inter` (also need attach license of it inside repo?)
 * get char widths for 0-1-2-3-4-5-6-7-8-9 with `pnum`
 * get char widths for 0-1-2-3-4-5-6-7-8-9 with `tnum`
 * if all values equals - it's means `tnum` not works. 
 * also - if font created without FigureWidth options, it's must be not equals to `tnum`

Maybe, maybe. For `tnum` we can validate each width for numbers per char. But - I think it's font part, we don't need test it

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

PR Comment: https://git.openjdk.org/jdk/pull/26144#issuecomment-3065083338

From asemenov at openjdk.org  Sat Jul 12 11:54:43 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Sat, 12 Jul 2025 11:54:43 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <WPvzinxBnR-M-HJHOrhvCJb-k1-zI2jUvtabqtNJqe8=.1b2b3c8d-56bf-4852-ba36-5b4740a68df9@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
 <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
 <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>
 <DNvqxX-AkQiCJYU3HGUh9Odm1kDYi4rw5DKshsbCRV0=.65931a07-bda4-4534-b65a-d206b9d02c72@github.com>
 <9Gpzi9EC2qKmhM7NPkpzBvD7DnL2b9ou5AgXOI1JB4o=.4420fad2-f732-4f37-a33c-4cae501242c1@github.com>
 <3Zqat_6_DwtqGjxNva7tUzaXPntvp5giE1dMrlSRwJo=.d081d6a5-a7e3-46f3-9108-f159ee08553a@github.com>
 <72C1WaCPTwiQ960VYIcvf_pp_42cyvQSHrQdhSmLfGU=.98079958-d0d2-435a-bbc7-e75dcf55f0d2@github.com>
 <WPvzinxBnR-M-HJHOrhvCJb-k1-zI2jUvtabqtNJqe8=.1b2b3c8d-56bf-4852-ba36-5b4740a68df9@github.com>
Message-ID: <QB9Msui3o9asiEpRD6Xz8S4EreSGP1JbebO_CcoolLw=.aa1a9690-32a9-4e81-a8b5-644cf30ebb53@github.com>

On Fri, 11 Jul 2025 07:02:07 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Thank you for the reference! However, I would like to advise you to thoroughly examine the code of TabGroupAccessibility. This is because it has its own implementations for creating child components.
>> 
>> Therefore, I am once again asking you to try to investigate the situation in more detail. There is a possibility that the mechanism is broken, and TabGroupAccessibility is not being created or used at all, which is incorrect.
>> 
>> Additionally, all objects in the hierarchy of native objects inherit from CommonComponentAccessibility in one way or another. If the accessibilityRoleDescription selector is not defined in TabGroupAccessibility, it may not be called.
>> 
>> I don?t have a Mac at hand right now; otherwise, I would debug this case myself and provide more detailed assistance.
>
> TabButtonAccessibility is initialized in TabGroupAccessibility but since TabButtonAccessibility is not exposed to accessible system (i.e. not createdwithaccessible) and hence a11y subsystem in unable to invoke the method.
> 
>> TabGroupAccessibility is not being created or used at all, which is incorrect.
> 
> TabGroupAccessibility does get created and the APIs are invoked by a11y subsystem. Once the accessibilityRoleDescription selector is defined in TabGroupAccessibility, it gets called but only when the self javarole is `pagetablist`.
> 
> After adding an entry for TabButtonAccessibility in rolesMap`[rolesMap setObject:@"TabButtonAccessibility" forKey:@"pagetab"]`, creates an accessible component for TabButtonAccessibility instead of CommonComponentAccessibility and is exposed to get invoked by a11y client. Then accessibilityRoleDescription API is invoked by a11y client.
> 
> But I am yet to find if there is any repercussion of adding the entry for TabButtonAccessibility.

Do not forget to increment [rolesMap capacity] before adding a role.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2202549936

From psadhukhan at openjdk.org  Sun Jul 13 09:12:27 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 13 Jul 2025 09:12:27 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v15]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <hKjP2gOKt4E954rI5oZPeirIpDUu2SHa2P8AYVIF1JU=.6ab9ce2f-4647-4cfd-a9da-02f03c281978@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:

 - Document NPE behaviour and update test and add class-level statement
 - Document NPE behaviour and update test and add class-level statement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/340254ec..dbf7edb0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=13-14

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

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

From psadhukhan at openjdk.org  Sun Jul 13 09:14:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 13 Jul 2025 09:14:42 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v12]
In-Reply-To: <K6XplxZ0jffXV-19bVu3Zuy7scj6tfOUnyI60Oeh7FI=.e4d8df92-99c2-455d-849f-0ab59fd6c0a8@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
 <i4BPuNcD8H3kyeVPAeAPaCvsBJbdG9NxVxVrzvfC58M=.78e4c633-fe9f-44f4-aea9-18483e532b1c@github.com>
 <v90zuPcY6O_xsW3sPIyQpM7PXrvQyRxae3NygbwspuA=.47b79d5c-1461-47ff-a9c1-f107b6d415ce@github.com>
 <K6XplxZ0jffXV-19bVu3Zuy7scj6tfOUnyI60Oeh7FI=.e4d8df92-99c2-455d-849f-0ab59fd6c0a8@github.com>
Message-ID: <lBFmAtGw32eE2mRI2f_pYV6DtYIeEgNiVQOopaOnXNQ=.869d1be0-c5e9-4625-9fdb-66227146dd1c@github.com>

On Fri, 11 Jul 2025 18:50:45 GMT, Phil Race <prr at openjdk.org> wrote:

> > > I think we need to have the "whole picture" tested to make sure everything does as we expect. It isn't so easy to tell even from looking at the source of ImageIcon. Then spec'ed so developers know what to expect. When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images Toolkit images are installed, even if they can't be used because the source isn't valid. They are "effectively" null, but not "actually" null. We should at least specify the null arg behaviours and try to say something about invalid image data. And as a result, I am now flipping to just documenting the setImage(null) NPE The protected method loadImage probably needs to say it too. Invalid image data, maybe we can cover that in a class level statement. Note: I'd like to see every constructor tested with both null and invalid image data.
> > 
> > 
> > I tested with null image/imagedata and invalid imagedata and it seems only these constructors throw NPE (current JDK) for null image (invalid image doesnt throw any exception)
> > ImageIcon(image, desc) ImageIcon(image) ImageIcon(byte[], desc) ImageIcon(byte[])
> > Current PR checks for null in ImageIcon(image) so it will not throw NPE but ImageIcon(byte[]) will still throw.. Should we handle those in separate PR and let this only be for setImage(null)?
> 
> You told me (off-line) that null URL also throws NPE and I see that too.
> 
> This class is a bit of a mess of accidental behaviours and scant documentation.
> 
> Let's document all the NPE behaviours and include a test that verifies it.
> 
> And invalid data like "new byte[0]" or null for a file name, or pointing to something that isn't an image file, or an invalid URL .. etc .. results in an Image instance being present, but it will never be completed so can never be drawn.
> 
> I think we need a class level statement like "If the image source parameter to a constructor is non-null, but does not reference valid accessible image data, no exceptions will be thrown but the image will be 'effectively' null, as it will have no dimensions and never be drawn, and getImageLoadStatus() will report ERRORED" - you should verify that last part but I think it is right.
> 
> We probably should add the similar text on setImage().
> 
> We can also test the invalid image data cases too.

Documented all NPE behavour and added class-level statement.
Updated test to verify it.
getImageLoadStatus() does return 4 which is ERRORED for invalid image, updated test reflects that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3066744236

From psadhukhan at openjdk.org  Sun Jul 13 11:04:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 13 Jul 2025 11:04:47 GMT
Subject: Integrated: 6955128: Spec for
 javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate
 wording
In-Reply-To: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
References: <YrucnkL77ZNg6LSLQJBGtQvn8Uie-tvo1SlG28Gwouk=.eec73f28-d50c-4744-8759-0f479eb6c5ee@github.com>
Message-ID: <SwOGx66D-ZkmsGxLB5QvndGMQAweA8TZOMgI1dm_eL4=.d0a173eb-7dcc-4f1c-a75f-4a9e7912394f@github.com>

On Tue, 17 Jun 2025 12:43:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> BasicTextUI.getVisibleEditorRect wording is rephrased to remove the wording "Due to an unfortunate set of historical events this method is inappropriately named".

This pull request has now been integrated.

Changeset: bc828c8f
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc828c8fb6693760c153a75188f96b1c9d201c8a
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

6955128: Spec for javax.swing.plaf.basic.BasicTextUI.getVisibleEditorRect contains inappropriate wording

Reviewed-by: aivanov, prr, dnguyen, abhiscxk, tr

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

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

From aivanov at openjdk.org  Sun Jul 13 20:08:39 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 13 Jul 2025 20:08:39 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
Message-ID: <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>

On Tue, 24 Jun 2025 11:44:13 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> `AccessibleText.getBeforeIndex` method returns `null for last characte`r due to the **wrong boundary value condition check**.
>> This method returns `null` when the `passed index parameter` is equal to `text's length` which is incorrect.
>> `getBeforeIndex` method should return `null` only if the **passed index parameter is less than 0 and greater than the text's length**.
>> 
>> After modifying the condition check, expected character is returned. Test is added to verify the check,
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test extended for WORD and SENTENCE

I modified Abhishek's test:


            System.out.println(" i  bef   at  aft");
            for (int i : new int[] {0, 1, 2, 8, 9, 10}) {
                System.out.printf("%2d%5s%5s%5s\n",
                                  i,
                                  at.getBeforeIndex(CHARACTER, i),
                                  at.getAtIndex(CHARACTER, i),
                                  at.getAfterIndex(CHARACTER, i));
            }


This way, I created a table of returned values:


Text: "0123456789"
Text Length: 10
 i  bef   at  aft
 0 null    0    1
 1    0    1    2
 2    1    2    3
 8    7    8    9
 9    8    9 null
10 null null null


I'd expect to see 9 as the return value of `getBeforeIndex` for the index of 10. This would make the table symmetrical.

Therefore, I'm in favour for Abhishek's proposed fix.

---

The description of the methods in `AccessibleText` is vague. None of the three methods specifies what the index means and what values are accepted for it.

According to the text model, index 10 is still valid, it's the index between the last character and the implied line break, so `tf.getDocument().getText(10, 1)` returns `\n`.

Having this in mind, the specification of the `getBeforeIndex`, `getAtIndex`, `getAfterIndex` methods should be updated to *explicitly specify the valid values for the `index` parameter*.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3067274720

From azvegint at openjdk.org  Mon Jul 14 03:46:55 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 14 Jul 2025 03:46:55 GMT
Subject: Integrated: 8360647: [XWayland] [OL10] NumPad keys are not triggered
In-Reply-To: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
References: <N7MejxiWF8Z9EN682-u9X3uyFwoTO9GyXo6riLeGyYA=.000471b7-eeb6-46ee-8600-7cdc0ca515f3@github.com>
Message-ID: <ZeEPn_eYHMgI3xxWAM-Ths2fMhGjZf_Kr5CJrL8m2Xs=.0586cc96-262f-4aae-8cc7-84e9a8a587cc@github.com>

On Mon, 7 Jul 2025 19:21:57 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
> 
> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.

This pull request has now been integrated.

Changeset: 0029554d
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0029554d20f22648994040a041c418d48a2a0eb4
Stats:     62 lines in 2 files changed: 41 ins; 3 del; 18 mod

8360647: [XWayland] [OL10] NumPad keys are not triggered

Reviewed-by: honkar, serb

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

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

From psadhukhan at openjdk.org  Mon Jul 14 05:20:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 14 Jul 2025 05:20:03 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v34]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <n6oinzhjh-wxJ08t4xQmqWlVBrH7KYs5a2le6yC2GGc=.b635bf46-2811-4d27-a99e-ac95c70f5ce3@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  bullet/checkmark placement for varying imageicon size fix, test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/103ef259..07175543

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=32-33

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

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

From psadhukhan at openjdk.org  Mon Jul 14 05:20:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 14 Jul 2025 05:20:04 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v33]
In-Reply-To: <icKQrBbjRkYWpZ6_bvPYUzAxHIsH-a4iQP510lHj6TU=.72699793-dacc-4cbc-8bc6-4fec98745f4e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>
 <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
 <icKQrBbjRkYWpZ6_bvPYUzAxHIsH-a4iQP510lHj6TU=.72699793-dacc-4cbc-8bc6-4fec98745f4e@github.com>
Message-ID: <jm4TovrGJTt7MZyM2ukXGPAwepasvagsG8GJNI3xdRQ=.d0415c97-19ef-404c-b05f-e9cbfcf087a2@github.com>

On Fri, 11 Jul 2025 21:10:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 932:
>> 
>>> 930:                                     skin.paintSkin(g, x + OFFSET, y + OFFSET, state);
>>> 931:                                 } else {
>>> 932:                                     if (icon.getIconHeight() > 16) {
>> 
>> Why does height > 16 matter ? How does it make icons align ?
>> 
>> Also - if that is satisfactorily answered then wouldn't the conditions here be more succinctly coded as 
>> 
>>                               if (icon == null || icon.getIconHeight() > 16) {
>>                                         skin.paintSkin(g, x + OFFSET, y + icon.getIconHeight() / 2, state);
>>                                      } else {
>>                                          skin.paintSkin(g, x + OFFSET, y + OFFSET, state);
>>                                      }
>
>> Why does height > 16 matter ? How does it make icons align ?
> 
> Perhaps, it's because standard Windows menu icons are 16?16; if the icon is larger something may need adjusting.
> 
> Yet I don't know the answer?

I am checking for 16 as Windows menu icon is of standard 16x16 size normally (and anything bigger is considered large referring to JDK-8182043) so didn't want to change the icon rendering height for normal,standard icons.

> Shouldn't Windows 10 do it the new way too ?

I didn't intentionally change the design for Windows 10 as that was the behaviour which was in existence (even though by "accident"  as we learnt) for so long our JDK code for Windows L&F is in existence, and some user might see the change (if we make Windows 11 and 10 same) and find it abrupt and not in sync to whatever they were seeing and "used to" till now

Also, there was no issue raised for Windows 10 about this behaviour so I believe it was same with native app.
Also, Windows 10 I believe is in its last leg and probable EOL in few months so thought of not changing the behaviour at this last moment.
Finally, any change to Windows 10 design will require extensive testing and I didn't have any Windows10 system so would have to rely on others and it would have been hard to replicate and fix if reported by others.

>> test/jdk/javax/swing/JMenuItem/TestRadioAndCheckMenuItemWithIcon.java line 31:
>> 
>>> 29:  *          JRadioButtonMenuItem and JCheckboxMenuItem
>>> 30:  *          is rendered with ImageIcon in WindowsLookAndFeel
>>> 31:  * @requires (os.family == "windows")
>> 
>> Can't we run this with all L&Fs on all platforms ? 
>> What about it would be so different in some other case ?
>> 
>> Also that last update for different sized icons isn't being tested - so can we vary the icon size in this test ?
>
> Should we run this test for all L&Fs?
> 
> So far, Windows L&F was unique in the way that it combined both check marks / bullets and icons. If we implement it the new way so that all the check marks / bullets and menu icons align, the menu behaviour in Windows L&F will be the same as that in Metal and Nimbus at least.
> 
> `javax/swing/JMenuItem/RightLeftOrientation.java` tests a similar scenario. If the behaviour of Windows L&F is the same as in other L&F, we may just add this bug id to an existing test.

We can but since the fix is in Windows I thought to make it Windows centric..Haven't quite tested in GTK or Aqua to see how it looks there..
I thought if we finalize the PR and settle on the design and it works fine, then we can look to extend the test later on to other platforms..
As of now, there is also a known issue in PassFailJFrame if multiple L&F are to be tested in iteration, it doesn't recreate its UI after testing for a L&F is complete so causing some exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2203865329
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2203864736
PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2203865428

From psadhukhan at openjdk.org  Mon Jul 14 05:20:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 14 Jul 2025 05:20:04 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v33]
In-Reply-To: <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>
 <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
Message-ID: <wx26S6csMJ7g1j4KurNdiax_qgiA5rAqPlW67YRwsII=.ab758d44-93ad-4350-869c-b8df547198fc@github.com>

On Fri, 11 Jul 2025 18:08:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust offset for varying size imageicon
>
> src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java line 947:
> 
>> 945:                     } else {
>> 946:                         icon.paintIcon(c, g, x + 6*OFFSET,
>> 947:                                 y + OFFSET);
> 
> Where did the magic multiplier of 6 come from ?

Nothing in particular, it's only for alignment..Since OFFSET here is a magic number and didn't have access to any of MenuLayoutHelper "gap" variables in this class so had to rely on this magic multiplier for aesthetic alignment.. 
But anyways modified now to not use magic number..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2203864999

From tr at openjdk.org  Mon Jul 14 05:29:45 2025
From: tr at openjdk.org (Tejesh R)
Date: Mon, 14 Jul 2025 05:29:45 GMT
Subject: RFR: 8361190: Test
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java fails on MacOS X
In-Reply-To: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
References: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
Message-ID: <RFMmZ69t2j6_VWlQwrGH7Pg1fXd_hbOEGPhvtHvfx2I=.6a6e98ad-869a-4bb9-ba32-b8aca9e932d5@github.com>

On Tue, 8 Jul 2025 16:34:31 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Add more timeout for the test to pass.

There are few integration blockers for this PR. Any particular reason for not having these fixes at one PR ?

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

PR Review: https://git.openjdk.org/jdk/pull/26196#pullrequestreview-3014808940

From jdv at openjdk.org  Mon Jul 14 06:06:42 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 14 Jul 2025 06:06:42 GMT
Subject: RFR: 8357034: GifImageDecoder can produce wrong transparent pixels
 [v6]
In-Reply-To: <kzNLoqMvrG0Gls8KnHlxy1KhQT-VGgLNs3cRphZuUuE=.b98c2075-65a4-4c8d-8c91-af0074a11b19@github.com>
References: <GUYwGm67UDdp9EdFhWJn4JWrykmlJhPSxvuvYVxuLJ8=.7bfb2e85-3d8e-42fc-9692-3c8258f1e021@github.com>
 <kzNLoqMvrG0Gls8KnHlxy1KhQT-VGgLNs3cRphZuUuE=.b98c2075-65a4-4c8d-8c91-af0074a11b19@github.com>
Message-ID: <tfj5zKG3Z7FprRdZzGsGrtnnTnEnxnO9JHNTziujoMQ=.92b6ea46-06f8-47f0-a76b-d0305f51563a@github.com>

On Fri, 11 Jul 2025 18:59:18 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> If there are two consecutive frames that use DISPOSAL_SAVE, but the transparent pixel index changed: we might accidentally send the wrong data to the ImageConsumer.
>> 
>> We already had logic that submits info "the hard way" (see comment in code); this PR just makes sure we trigger that block.
>> 
>> There are a cluster of four related PRs that share the GifComparison class in this PR.
>> 
>> 1. [8357034](https://github.com/openjdk/jdk/pull/25264) (this one)
>> 2. ~~[8356137](https://github.com/openjdk/jdk/pull/25044)~~ (integrated)
>> 3. [8356320](https://github.com/openjdk/jdk/pull/25076)
>> 4. [8351913](https://github.com/openjdk/jdk/pull/24271)
>> 
>> This bug can be observed reading these gif animations:
>> 
>> https://giphy.com/gifs/fomoduck-duck-fomo-ZUlzR40oGACqNmy0q8
>> https://media4.giphy.com/media/Zbf4JQzcDhzeraQvk9/giphy.gif
>> https://giphy.com/gifs/computer-working-cat-LHZyixOnHwDDy
>> https://giphy.com/gifs/90s-fgfgif-r4BmI9xUaDuKJQdd3l
>
> Jeremy Wood has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - 8357034: re-wrapping line breaks
>  - 8356137, 8357034: add debug option to dump PNGs of frames
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-3007487527
>  - Merge branch 'master' into JDK-8357034
>    
>    # Conflicts:
>    #	test/jdk/sun/awt/image/gif/GifBuilder.java
>    #	test/jdk/sun/awt/image/gif/GifComparison.java
>  - 8357034: avoid recalculating isSimpleSavedImageComparison for every line
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25264#discussion_r2197097522
>  - Merge branch 'master' into JDK-8357034
>  - 8356320: Use new GifBuilder and remove ukraine-flag.gif
>    
>    This is an extension of work for this PR:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: adding copyright
>  - 8356137: Adding GifBuilder to dynamically create test file
>    
>    This can be used by multiple gif tests in this directory.
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#pullrequestreview-2871107750
>  - 8356137: trivial javadoc update
>  - 8356137: only inspect last frame of gif
>    
>    This makes the main() method much less useful, so I removed it too. (I originally used this class to explore a folder of hundreds of gifs to look for discrepancies. But the discrepancies were rarely only on the last frame.)
>    
>    This is in response to:
>    https://github.com/openjdk/jdk/pull/25044#discussion_r2109298270
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/a86dd56d...7c96ce19

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25264#pullrequestreview-3014869222

From abhiscxk at openjdk.org  Mon Jul 14 08:36:57 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 14 Jul 2025 08:36:57 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v4]
In-Reply-To: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
Message-ID: <PxraFDnGTaBbv8TKEkJYLR97I95Whzhmf8oWXb9f4bc=.fde406a7-7736-4fa7-a820-d3ff80b96c44@github.com>

> **Issue** : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
> 
> **Analysis** : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
> 
> **Proposed Fix** : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.
> 
> **Testing** : Manual test case has been added to verify the fix.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Role description code moved to TabButtonAccessibility

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26096/files
  - new: https://git.openjdk.org/jdk/pull/26096/files/7d0b9379..bfaf0100

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

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

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

From abhiscxk at openjdk.org  Mon Jul 14 08:36:58 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 14 Jul 2025 08:36:58 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v2]
In-Reply-To: <QB9Msui3o9asiEpRD6Xz8S4EreSGP1JbebO_CcoolLw=.aa1a9690-32a9-4e81-a8b5-644cf30ebb53@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <k3k8kFNQiFGMxbi_JulDTHQTXBzhtWRUJo5vWvB-UHo=.fea80352-7540-4e09-8413-4d1281db33db@github.com>
 <SFxKz3nUE7uFWbBFJy5pnB7BNevgZzu2D_TdhAwHBWo=.4447efc7-974a-4f7c-add2-fc09ef405b45@github.com>
 <qo8LHSi-HwLta6oAUOrbkqAKOwzB4PUdh5GpfYeWLtc=.51d075bd-006c-4b3f-b382-3412756bcd02@github.com>
 <tAdXUyGuw2ratfMXfJU8V-VukF4FbYCHTUefvGSUtwA=.e872a2d5-80e4-4f6a-849a-448871a3e426@github.com>
 <DNvqxX-AkQiCJYU3HGUh9Odm1kDYi4rw5DKshsbCRV0=.65931a07-bda4-4534-b65a-d206b9d02c72@github.com>
 <9Gpzi9EC2qKmhM7NPkpzBvD7DnL2b9ou5AgXOI1JB4o=.4420fad2-f732-4f37-a33c-4cae501242c1@github.com>
 <3Zqat_6_DwtqGjxNva7tUzaXPntvp5giE1dMrlSRwJo=.d081d6a5-a7e3-46f3-9108-f159ee08553a@github.com>
 <72C1WaCPTwiQ960VYIcvf_pp_42cyvQSHrQdhSmLfGU=.98079958-d0d2-435a-bbc7-e75dcf55f0d2@github.com>
 <WPvzinxBnR-M-HJHOrhvCJb-k1-zI2jUvtabqtNJqe8=.1b2b3c8d-56bf-4852-ba36-5b4740a68df9@github.com>
 <QB9Msui3o9asiEpRD6Xz8S4EreSGP1JbebO
 _CcoolLw=.aa1a9690-32a9-4e81-a8b5-644cf30ebb53@github.com>
Message-ID: <NwC3NcyixwHx1p_vtsOQgFAl2lalQAaKsTF1zpZgndc=.4b8894f7-706b-4ce8-9f18-633c425b7829@github.com>

On Sat, 12 Jul 2025 11:51:52 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> TabButtonAccessibility is initialized in TabGroupAccessibility but since TabButtonAccessibility is not exposed to accessible system (i.e. not createdwithaccessible) and hence a11y subsystem in unable to invoke the method.
>> 
>>> TabGroupAccessibility is not being created or used at all, which is incorrect.
>> 
>> TabGroupAccessibility does get created and the APIs are invoked by a11y subsystem. Once the accessibilityRoleDescription selector is defined in TabGroupAccessibility, it gets called but only when the self javarole is `pagetablist`.
>> 
>> After adding an entry for TabButtonAccessibility in rolesMap`[rolesMap setObject:@"TabButtonAccessibility" forKey:@"pagetab"]`, creates an accessible component for TabButtonAccessibility instead of CommonComponentAccessibility and is exposed to get invoked by a11y client. Then accessibilityRoleDescription API is invoked by a11y client.
>> 
>> But I am yet to find if there is any repercussion of adding the entry for TabButtonAccessibility.
>
> Do not forget to increment [rolesMap capacity] before adding a role.

Moved the role description code to TabButtonAccessibility file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26096#discussion_r2204216487

From duke at openjdk.org  Mon Jul 14 09:25:39 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Mon, 14 Jul 2025 09:25:39 GMT
Subject: RFR: 8361190: Test
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java fails on MacOS X
In-Reply-To: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
References: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
Message-ID: <sqBxUvaywK_GWFSy_7nKsIi_WlyBPT-94CyXaGW7awg=.a761ed0e-5f4a-46e8-b4d8-bf48fe7267e3@github.com>

On Tue, 8 Jul 2025 16:34:31 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Add more timeout for the test to pass.

I thought it will explain better the relation between different tests and fixes. I understand that this will increase the chain of dependencies between PRs. Please let me know if it is better to group these PRs in one.

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

PR Comment: https://git.openjdk.org/jdk/pull/26196#issuecomment-3068600037

From ngubarkov at openjdk.org  Mon Jul 14 13:30:44 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Mon, 14 Jul 2025 13:30:44 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features [v3]
In-Reply-To: <OZQyntt4IjrxJGh2DoskSQYyTIyaNtp0bzEJH7wBWvs=.d21e8b10-7c5a-4dbf-8904-6f6a8e5b6529@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
 <OZQyntt4IjrxJGh2DoskSQYyTIyaNtp0bzEJH7wBWvs=.d21e8b10-7c5a-4dbf-8904-6f6a8e5b6529@github.com>
Message-ID: <-v119HjhPbCpYFS8V_JWE9fvLboqTsD20XTzBycUUZc=.265ee05b-28b7-4330-b3c3-eed4eb3a378c@github.com>

On Sat, 12 Jul 2025 08:21:23 GMT, Valery Semenchuk <duke at openjdk.org> wrote:

>> Introducing to API constants, and implementation for controlling Figure Styles
>> 
>> Target font: *Inter*
>> 
>> Example screenshot 
>> 
>> ![image](https://github.com/user-attachments/assets/e19af8ad-9809-4a0a-8a30-60921e490bd4)
>
> Valery Semenchuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix wrong import reformat

Given that this needs to go through specification review anyway, I suggest to consider the more general solution with passing arbitrary OpenType features instead of a few more attributes. This would definitely be beneficial for other AWT users.
We have similar functionality implemented in JBR after requests of JetBrains users, wanting to customize their font appearance: https://github.com/JetBrains/JetBrainsRuntime/commit/a2900b0bd998fc788f7b34fa9cf04493e21ad50f

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

PR Comment: https://git.openjdk.org/jdk/pull/26144#issuecomment-3069621364

From ngubarkov at openjdk.org  Mon Jul 14 13:46:40 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Mon, 14 Jul 2025 13:46:40 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features
In-Reply-To: <pbR1Da7KATa7bQ2hVoGR3dm5QIdqzUgdzPfA1IFYmlU=.4b1910ee-7b7d-4ecd-b239-6c896c79dcc4@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
 <foHud3SBXwVBkUVmYRoKO5ybxJUGpYgs3938DCG4vR4=.77d6fce3-8540-4fec-9c8c-78725182d1a4@github.com>
 <pbR1Da7KATa7bQ2hVoGR3dm5QIdqzUgdzPfA1IFYmlU=.4b1910ee-7b7d-4ecd-b239-6c896c79dcc4@github.com>
Message-ID: <1w4F6Xm6XdTuuErRsQUyXhCa7DYd_P7MKctT6SkNeC4=.88032ea8-9f51-40dd-ad33-d6a1ba8f9b99@github.com>

On Sat, 12 Jul 2025 11:12:16 GMT, Valery Semenchuk <duke at openjdk.org> wrote:

>> I have changed the bug summary so you will need to change the PR summary to match -
>> 8360136: RFE: Add TextAttributes for OpenType font figure style features
>
> @prrace about tests. I can draw test image with font which is support tnum feature, and validate without it. Primitive one.
> 
> For example
>  * at start - need load font, which supports this features. For example `Inter` (also need attach license of it inside repo?)
>  * draw image `0123456789` with `pnum` 
>  * <img width="200" height="50" alt="pnum" src="https://github.com/user-attachments/assets/2e80a463-a608-425f-a264-6097e415d397" />
>  * draw image `0123456789` with `tnum`
>  * <img width="200" height="50" alt="tnum" src="https://github.com/user-attachments/assets/62600f4e-1094-4fce-bd09-3876b4a8610e" />
>  * if all bytes of images equals - it's means `tnum` not works. 
> 
> Also check default instance of `Font` without options
> 
> We can add this images inside repo, and validate image drawing (not sure)

@VISTALL You can take a look at https://github.com/openjdk/jdk/blob/bcd86d575fe0682a234228c18b0c2e817d3816da/test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java - it has a good example of synthetic font generated specifically for the test and embedded into the test as base64. This avoids the hussle with licences and whatnot.
I would also suggest to avoid golden-image tests, as those tend to be burdensome to maintain. But in your case you can probably inspect line metrics and compare the widths of a sample text.

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

PR Comment: https://git.openjdk.org/jdk/pull/26144#issuecomment-3069670489

From duke at openjdk.org  Mon Jul 14 14:07:39 2025
From: duke at openjdk.org (Valery Semenchuk)
Date: Mon, 14 Jul 2025 14:07:39 GMT
Subject: RFR: 8360136: RFE: Add TextAttributes for OpenType font figure
 style features
In-Reply-To: <1w4F6Xm6XdTuuErRsQUyXhCa7DYd_P7MKctT6SkNeC4=.88032ea8-9f51-40dd-ad33-d6a1ba8f9b99@github.com>
References: <VNAXUTj95WdYfxzGv__xrzETY-L9nHiw0P7Y7nihhqc=.8a5c27c6-eb50-4a0c-91ed-a9bfb1df36e2@github.com>
 <foHud3SBXwVBkUVmYRoKO5ybxJUGpYgs3938DCG4vR4=.77d6fce3-8540-4fec-9c8c-78725182d1a4@github.com>
 <pbR1Da7KATa7bQ2hVoGR3dm5QIdqzUgdzPfA1IFYmlU=.4b1910ee-7b7d-4ecd-b239-6c896c79dcc4@github.com>
 <1w4F6Xm6XdTuuErRsQUyXhCa7DYd_P7MKctT6SkNeC4=.88032ea8-9f51-40dd-ad33-d6a1ba8f9b99@github.com>
Message-ID: <_Z3opP9ze9fLvliBDmd73kjDaEYpXXR3P6Hi7v8mpYc=.a80e2361-4b3b-4e4f-acaf-8e1473aec2cd@github.com>

On Mon, 14 Jul 2025 13:43:40 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> @prrace about tests. I can draw test image with font which is support tnum feature, and validate without it. Primitive one.
>> 
>> For example
>>  * at start - need load font, which supports this features. For example `Inter` (also need attach license of it inside repo?)
>>  * draw image `0123456789` with `pnum` 
>>  * <img width="200" height="50" alt="pnum" src="https://github.com/user-attachments/assets/2e80a463-a608-425f-a264-6097e415d397" />
>>  * draw image `0123456789` with `tnum`
>>  * <img width="200" height="50" alt="tnum" src="https://github.com/user-attachments/assets/62600f4e-1094-4fce-bd09-3876b4a8610e" />
>>  * if all bytes of images equals - it's means `tnum` not works. 
>> 
>> Also check default instance of `Font` without options
>> 
>> We can add this images inside repo, and validate image drawing (not sure)
>
> @VISTALL You can take a look at https://github.com/openjdk/jdk/blob/bcd86d575fe0682a234228c18b0c2e817d3816da/test/jdk/java/awt/font/TextLayout/FormatCharAdvanceTest.java - it has a good example of synthetic font generated specifically for the test and embedded into the test as base64. This avoids the hussle with licences and whatnot.
> I would also suggest to avoid golden-image tests, as those tend to be burdensome to maintain. But in your case you can probably inspect line metrics and compare the widths of a sample text.

@YaaZ Thanks for example. About API. Will be good to make universal api - but I think it's too big task will be.

Maybe introduce api like nio2 - CopyOption* etc.

for example 


interface FontFeature<V> (FontExtension?) {
   // some code
}

// V is Integer? or delegate to impl
class OpenTypeFontFeature implements FontFeature<Integer > {
   OpenTypeFontFeature (String name) {
   }
}

public final class OpenTypeFontFeatures {
    FontFeature<Integer> TNUM = new OpenTypeFontFeature ("tnum");
} 



There few questions:
  * conflicting features?
  * need method `Font#supportsFeature(FontFeature)` ?
  * need opentype class? or utilize to default font naming? (get FontFeatureImpl)
  * need make public `OpenTypeFontFeature` class? (accesing from clients)
  * FontFeature can extend TextAttribute?

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

PR Comment: https://git.openjdk.org/jdk/pull/26144#issuecomment-3069742252

From kizune at openjdk.org  Mon Jul 14 16:23:40 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 14 Jul 2025 16:23:40 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character
In-Reply-To: <RTpQD-ESC1E5Gh_Q9ztd2cj7qgVri9aEyusuEzPSTps=.71b33672-0159-4699-ae7e-9c1381d18e87@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <KKjs4kAJW8kZE99lSEYpcOXyPvCxyNRfUQ6mB3fEYX0=.23a59cb6-21db-4b63-a844-96ddb1da14a1@github.com>
 <K8BRT3nS8fc0MJ6h3P1XNm_LNOwuhnxcZ-IqfiTDIxY=.94afafd8-b860-4426-9a9f-0bdf021062cc@github.com>
 <Cfrn8_ovavY9WJeSpmYju8k1I2jXg07XU-ON8DPhGZM=.39a0daf6-4150-406b-8add-e38b409318cd@github.com>
 <RTpQD-ESC1E5Gh_Q9ztd2cj7qgVri9aEyusuEzPSTps=.71b33672-0159-4699-ae7e-9c1381d18e87@github.com>
Message-ID: <qcKeXI1fc58hkmQrz0b6xFmgLFwkfkum01R3k8ky5Kw=.7397cc85-f5f7-46c9-bff1-010866a6c5ca@github.com>

On Wed, 25 Jun 2025 04:43:14 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> I got your point now. The spec says that `index an index within the text` and that means the value should range from 0 to length - 1. And that means, `getBeforeIndex` won't be able to fetch the last character and `getAfterIndex` won't be able to fetch the first character.

Here i disagree, the "within the text" does not imply that the position behind the last character is not within the text. Otherwise with the caret is at the end of the text it is impossible to request last word or character before the caret position which is one of the valid use cases of this accessibility method. I think the fix is valid.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3070187941

From achung at openjdk.org  Mon Jul 14 16:45:04 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 14 Jul 2025 16:45:04 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v15]
In-Reply-To: <uXdIKOC0Dk1TyKoKgkcCIUAKbzK7DQPtGCfHADhKOaM=.8ab91987-47da-441a-92a0-eb46394b8e60@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <xdbhtBgikqvegs36jK5HQykyZPSHJ_hhB5xDCg_dqxw=.97a8c90f-4b87-406a-b0a7-1c73722f1e26@github.com>
 <Idbkr_1O6El_xQd5NqPpe4wvCrnN7ILYcH7lK2nx-3w=.9a87e19e-f975-4820-8b89-c066c233301c@github.com>
 <rwkuHsqWQfZZAFxpylJZHZnPcWHJ1f0O2KimS7WbGxw=.2a3d404c-3000-4943-a3d9-dd619529aebc@github.com>
 <uXdIKOC0Dk1TyKoKgkcCIUAKbzK7DQPtGCfHADhKOaM=.8ab91987-47da-441a-92a0-eb46394b8e60@github.com>
Message-ID: <4j848QB5obloOLj1hQ4zyznEFCglKuZQCjC35fT8f1o=.25596cde-0174-4c34-b152-0147d2374560@github.com>

On Fri, 11 Jul 2025 20:10:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> "glide  has over-rides step length"
>> 
>> Sorry, that text was not clear. What I mean is that glide(..) accepts delay and step parameters, and so at least in that case you can over-ride with your preferred values.
>> 
>> Other than that, it isn't configurable in the ExtendedRobot, so the need isn't clear.
>> 
>> Even so, we could do this but whether now or later, but in either case,
>> we ought to think now as to what it would look like so it can be compatibly added.
>> 
>> In ExtendedRobot the equivalent fields are private but here they are public.
>> Tests might start to use them directly. I'm not sure what for, but they might.
>> But if it is configurable tests probably should instead  call a getter() for the currently set delay/step.
>> 
>> Then all the methods that now mention DEFAULT_ would probably need to mention something like
>> getMouseDelay() and getStepLength() instead.
>> 
>> So it may be better to do it now ? Thoughts ?
>
> @alisenchung did you see the above ? 
> Looks like email for it may not have been generated because I *edited* an old comment rather than adding a new one.

I think setting the default step length with a setter/getter makes sense. I think generally tests don't change the step delays across their glides anyway and it would remove the need for all those extra overrides for glide. I'll make this change now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2205359550

From abaya at openjdk.org  Mon Jul 14 17:06:28 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 14 Jul 2025 17:06:28 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux
Message-ID: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>

**Analysis:**
The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.

**Proposed Fix:**
We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once

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

Commit messages:
 - Avoid recursive re-entering

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

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

From achung at openjdk.org  Mon Jul 14 19:23:43 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 14 Jul 2025 19:23:43 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v24]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <Kcyd2F0371yQ4l1UmIPffV4akj3NqhozujO1s_qXERY=.dc2a7c67-98fe-4231-8092-5a0080eae44a@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - removed click/type delay field, added setters and getters for step delay/length for glide, removed glide override for setting explicit step delay/legnth
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
 - update robot specs
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
 - remove ER from remaining modal test
 - remove /lib/client/ from tests with ER removed
 - update tests, remove extended robot from some tests
 - update tests
 - synchronized for type(char)
 - migrate type(char) method
 - ... and 24 more: https://git.openjdk.org/jdk/compare/f5afbbd3...41934c61

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

Changes: https://git.openjdk.org/jdk/pull/22044/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=23
  Stats: 1077 lines in 244 files changed: 265 ins; 447 del; 365 mod
  Patch: https://git.openjdk.org/jdk/pull/22044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044

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

From achung at openjdk.org  Mon Jul 14 19:26:01 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 14 Jul 2025 19:26:01 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v23]
In-Reply-To: <OWeQEnalivyjSTJibr3FF8OVLIHDdEbq6eL4GtNPEnM=.6125e11d-8adf-4c33-b091-a18384a6e203@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <OWeQEnalivyjSTJibr3FF8OVLIHDdEbq6eL4GtNPEnM=.6125e11d-8adf-4c33-b091-a18384a6e203@github.com>
Message-ID: <eCqPuUK4GnI39yPPSCnTgviApvys74BXEEJ7vN1ykxo=.319b04d6-034f-40c7-8453-917b074eba18@github.com>

On Thu, 10 Jul 2025 15:29:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - update robot specs
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
>  - remove ER from remaining modal test
>  - remove /lib/client/ from tests with ER removed
>  - update tests, remove extended robot from some tests
>  - update tests
>  - synchronized for type(char)
>  - migrate type(char) method
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8150564
>  - remove specified numbers in constant fields, add exception to documentation in glide
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/3bcbcc57...c02d4183

I've decided to remove click/type's usage of the default step-delay and just forced them to use a delay of 20ms since I don't think anyone would need to explicitly set a delay for clicking and typing. I also made the step delay/length to be configurable for glide and added setters/getters for them. Because of that I removed the last glide override that explicitly set the delay and length.

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

PR Comment: https://git.openjdk.org/jdk/pull/22044#issuecomment-3070699211

From duke at openjdk.org  Mon Jul 14 20:22:50 2025
From: duke at openjdk.org (mezz)
Date: Mon, 14 Jul 2025 20:22:50 GMT
Subject: RFR: 8359053: Implement JEP 504 - Remove the Applet API [v10]
In-Reply-To: <5hv53zmZA9kKblG14CHqjUjg1tXK_y6RePXkaRKbXAI=.0dc6287e-1af8-402f-862f-cc2da1075909@github.com>
References: <T2zHND6GxyMkHH2PmGRo1Xr4FLYsrPCrX5dDhfKBBe4=.05d87c0d-a9e6-47b7-bb45-3b73c1fd15b8@github.com>
 <JmmOSkORy-UpU_xBaa1v2dkB1rRHL54C-Ymu0-c2I1o=.85a0e584-629c-404e-b260-148760ea7c66@github.com>
 <5hv53zmZA9kKblG14CHqjUjg1tXK_y6RePXkaRKbXAI=.0dc6287e-1af8-402f-862f-cc2da1075909@github.com>
Message-ID: <KQHnEW0I6sTQLd3pCUlg0cLUpPGrQZX5t8NCI6CEaGY=.429759a8-2e69-438d-85bd-ffd1f881170c@github.com>

On Mon, 23 Jun 2025 19:42:10 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 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.

Right, "per VM" means "for each VM". This is a minor mistake I've made many times
Suggestion:

      and now with single application per VM, there is no

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

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

From prr at openjdk.org  Mon Jul 14 20:26:54 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 14 Jul 2025 20:26:54 GMT
Subject: Integrated: 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: <iP20Wg2DqRQ2IpHDDcwGIgraU32z3qhA5DQWOWAHF7g=.20bad0ba-6f59-4ef6-b82e-456e6e03b31b@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.

This pull request has now been integrated.

Changeset: 5cf672e7
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cf672e7784b9a9a82f29977a072b162cc240fd1
Stats:     3261 lines in 86 files changed: 124 ins; 2966 del; 171 mod

8359053: Implement JEP 504 - Remove the Applet API

Reviewed-by: aivanov, kizune, kcr, achung, serb

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

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

From azvegint at openjdk.org  Mon Jul 14 21:05:42 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 14 Jul 2025 21:05:42 GMT
Subject: RFR: 8358468: Enhance code consistency: java.desktop/macos [v2]
In-Reply-To: <5zViysAQgPCSlPiwX0rYfNdBCzpf-y3yquFZd426xi4=.f8a708fc-0729-481d-a581-24a5e3894c19@github.com>
References: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
 <5zViysAQgPCSlPiwX0rYfNdBCzpf-y3yquFZd426xi4=.f8a708fc-0729-481d-a581-24a5e3894c19@github.com>
Message-ID: <VlLU2tuM104iDt6s118UdjsUxpBFllQTGHEDkM5NRHo=.60a97631-2d74-4c34-b0ad-c1de957181bb@github.com>

On Fri, 11 Jul 2025 18:35:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This PR updates the last (!!) remaining platform-specific part of the java.desktop module: macos.
>> The unix/windows were previously addressed in: https://github.com/openjdk/jdk/pull/24170 , https://github.com/openjdk/jdk/pull/24941 and https://github.com/openjdk/jdk/pull/25439.
>> 
>> Note: Unlike on other platforms, the initial change for macOS caused the "BadSerializationTest" to fail. This test relies on internal details of the Aqua Look & Feel that were previously exposed via serialized data (and already [fails](https://bugs.openjdk.org/browse/JDK-8277817) on other platforms). Adding the final modifier to the class changes its serialVersionUID, which triggered the failure even on macOS.
>> To avoid this issue, I have reverted the changes to those internal classes for now, see https://github.com/openjdk/jdk/pull/25607/commits/ff7e64b6e38a1a809d434628f304e49408135697
>> 
>> To download the diff file and filter only the modified lines you can use the following script:
>> 
>> 
>> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff -o d.txt && grep -E '^+|^-' d.txt | grep -vE '^+++|^---'
>> 
>> ====================================================
>> 
>> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
>> 
>> The public API was not affected so there is no need to worry about a CSR
>> 
>> Note: I will submit additional patches in this area later because:
>> 
>> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
>> 2. I skipped adding `@Override` for anonymous classes
>> 
>> Any feedback or suggestions are welcome!
>> 
>> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff) to a simple diff file, it might be more convenient for reviewing the changes.
>> 
>> The build was successful, and I ran all the open jtreg tests without issues. But...
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into over_macos
>  - Fix java/awt/dnd/BadSerializationTest/BadSerializationTest.java test
>  - restore formatting
>  - final in java.desktop/macos
>  - override in java.desktop/macos

Marked as reviewed by azvegint (Reviewer).

src/java.desktop/macosx/classes/com/apple/laf/AquaFonts.java line 38:

> 36: 
> 37: @SuppressWarnings("serial") // JDK implementation class
> 38: public final class AquaFonts {

This final class has two protected methods:


protected static FontUIResource getMiniControlTextFont() {
protected static FontUIResource getSmallControlTextFont() {


There may be more, but I suppose this can be handled as a separate issue.

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

PR Review: https://git.openjdk.org/jdk/pull/25607#pullrequestreview-3017737749
PR Review Comment: https://git.openjdk.org/jdk/pull/25607#discussion_r2205783736

From azvegint at openjdk.org  Mon Jul 14 21:25:42 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 14 Jul 2025 21:25:42 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
Message-ID: <RRPm8UiUOhc8m-cxtZs_E9rZZvsk3LvNzN72utxBfhU=.67aa043b-2551-47cb-a35e-4115294efd2f@github.com>

On Thu, 24 Apr 2025 09:29:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner.
> `invalidComponents` is an ArrayList.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24845#pullrequestreview-3017878940

From abaya at openjdk.org  Mon Jul 14 21:26:56 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 14 Jul 2025 21:26:56 GMT
Subject: RFR: 8346952 : GetGraphicsStressTest.java fails: Native resources
 unavailable [v12]
In-Reply-To: <btkm6weIakViZ7Vt4iSqIZNI7kKbJFzbGv3K804jqFo=.8aa3710f-85a9-4cb1-b6b6-4084754be47b@github.com>
References: <IZIhhbpiQldVRXt6FSVFRg9z_UNrsPN-xGjJNrufb8A=.0e1aefc5-e1d1-4b83-a764-72f632c18c48@github.com>
 <pwlkCyB7cJXvjveWngQS-mG9JwnHhvSZPB0HjBExlxU=.bd744d82-3591-46e2-ae37-5e8eddff3f95@github.com>
 <btkm6weIakViZ7Vt4iSqIZNI7kKbJFzbGv3K804jqFo=.8aa3710f-85a9-4cb1-b6b6-4084754be47b@github.com>
Message-ID: <zPZfxH33DM2uAzRwRqc6i2wRhTG2Hi20IDVmmVFwAlA=.c47d13e7-2a80-4671-9689-8d1774e3316f@github.com>

On Mon, 30 Jun 2025 04:27:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Anass Baya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove trailing space
>
> Marked as reviewed by serb (Reviewer).

Hello @mrserb,
The proposed test is causing an issue on Linux. So I have submitted the PR https://github.com/openjdk/jdk/pull/26298 to address that
Thank you

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

PR Comment: https://git.openjdk.org/jdk/pull/25619#issuecomment-3071035513

From achung at openjdk.org  Mon Jul 14 21:49:39 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 14 Jul 2025 21:49:39 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux
In-Reply-To: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
Message-ID: <fTasWmvNU9fp_Tcf2qu3xfkpM56jNd-BJiZh21L9Vw0=.6d01bc63-a9e9-47dd-9638-abc86c29a06c@github.com>

On Mon, 14 Jul 2025 17:00:35 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Analysis:**
> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
> 
> **Proposed Fix:**
> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once

After this test fix does the test fail if you undo [JDK-8346952](https://github.com/openjdk/jdk/pull/25619)?

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

PR Review: https://git.openjdk.org/jdk/pull/26298#pullrequestreview-3017923468

From abaya at openjdk.org  Mon Jul 14 23:02:38 2025
From: abaya at openjdk.org (Anass Baya)
Date: Mon, 14 Jul 2025 23:02:38 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux
In-Reply-To: <fTasWmvNU9fp_Tcf2qu3xfkpM56jNd-BJiZh21L9Vw0=.6d01bc63-a9e9-47dd-9638-abc86c29a06c@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
 <fTasWmvNU9fp_Tcf2qu3xfkpM56jNd-BJiZh21L9Vw0=.6d01bc63-a9e9-47dd-9638-abc86c29a06c@github.com>
Message-ID: <nLvrP_kOs_AxFtJGPPxNDQE0kJWV-c2nAaygPtbHJLg=.f17ad5f6-25db-48c7-95fa-d94e8a3f0cec@github.com>

On Mon, 14 Jul 2025 21:47:10 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> **Analysis:**
>> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
>> 
>> **Proposed Fix:**
>> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
>> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once
>
> After this test fix does the test fail if you undo [JDK-8346952](https://github.com/openjdk/jdk/pull/25619)?

Hello @alisenchung,
Yes we can reproduce the issue using this updated test
BR,

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

PR Comment: https://git.openjdk.org/jdk/pull/26298#issuecomment-3071278002

From serb at openjdk.org  Tue Jul 15 02:54:42 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 02:54:42 GMT
Subject: RFR: 8358468: Enhance code consistency: java.desktop/macos [v2]
In-Reply-To: <VlLU2tuM104iDt6s118UdjsUxpBFllQTGHEDkM5NRHo=.60a97631-2d74-4c34-b0ad-c1de957181bb@github.com>
References: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
 <5zViysAQgPCSlPiwX0rYfNdBCzpf-y3yquFZd426xi4=.f8a708fc-0729-481d-a581-24a5e3894c19@github.com>
 <VlLU2tuM104iDt6s118UdjsUxpBFllQTGHEDkM5NRHo=.60a97631-2d74-4c34-b0ad-c1de957181bb@github.com>
Message-ID: <Vxz7D0Zn0ZfqqMqmPbV_-dkuDjT1qKoiltUAi5YG5Hs=.3f8eb205-39ec-4f7d-9319-2f2ae897a24a@github.com>

On Mon, 14 Jul 2025 20:47:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into over_macos
>>  - Fix java/awt/dnd/BadSerializationTest/BadSerializationTest.java test
>>  - restore formatting
>>  - final in java.desktop/macos
>>  - override in java.desktop/macos
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaFonts.java line 38:
> 
>> 36: 
>> 37: @SuppressWarnings("serial") // JDK implementation class
>> 38: public final class AquaFonts {
> 
> This final class has two protected methods:
> 
> 
> protected static FontUIResource getMiniControlTextFont() {
> protected static FontUIResource getSmallControlTextFont() {
> 
> 
> There may be more, but I suppose this can be handled as a separate issue.

Yes, it intentionally includes only this change, which might already be too large to review. However, there will be more follow-ups.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25607#discussion_r2206172387

From serb at openjdk.org  Tue Jul 15 02:55:41 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 02:55:41 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux
In-Reply-To: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
Message-ID: <ek7aLf2QVQEnSsW-6w9Sel4n_Vu1fv-v6DYwAJzkQEQ=.d85ac524-74a0-478e-a6cf-a6a790d4b22e@github.com>

On Mon, 14 Jul 2025 17:00:35 GMT, Anass Baya <abaya at openjdk.org> wrote:

> **Analysis:**
> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
> 
> **Proposed Fix:**
> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once

I do not think this is a bug in the test, the jdk should survive this.

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

PR Comment: https://git.openjdk.org/jdk/pull/26298#issuecomment-3071718648

From serb at openjdk.org  Tue Jul 15 02:57:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 02:57:40 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
Message-ID: <fEZ65uvpR1YG8eaa51LvYHfTLjJts2xvjBX43awsoEs=.b3520876-5151-46a4-accd-d03d0f36e02c@github.com>

On Thu, 24 Apr 2025 09:29:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner.
> `invalidComponents` is an ArrayList.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24845#pullrequestreview-3018341187

From serb at openjdk.org  Tue Jul 15 04:01:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 04:01:58 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
Message-ID: <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>

On Sun, 13 Jul 2025 20:06:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>I'd expect to see 9 as the return value of getBeforeIndex for the index of 10. This would make the table symmetrical.

Why do you expect that? The spec states that the index should be "an index within the text." That index is also used in other methods, such as getCharacterBounds(), etc. If we fixed it only for text at the end, it would make the behavior even less symmetric, since for a negative value, the model will always throw an exception.

>According to the text model, index 10 is still valid, it's the index between the last character and the implied line break, so tf.getDocument().getText(10, 1) returns \n.

The last character is implementation detail, it is not part of the "users data" this is the reason why it is excluded from the Document.getLength(). So passing length as a last character might cause an exception for custom documents. We also have the getCharCount() methods which returns "the number of characters (valid indices)".

Also, why are we only talking about JTextComponent? There are other same implementations of AccessibleText for example [JLabel](https://github.com/openjdk/jdk/blob/0acd065bf5a75090b84c28b28856a62d86c52791/src/java.desktop/share/classes/javax/swing/JLabel.java#L1287).

>Here i disagree, the "within the text" does not imply that the position behind the last character is not within the text. Otherwise with the caret is at the end of the text it is impossible to request last word or character before the caret position which is one of the valid use cases of this accessibility method. I think the fix is valid.

It means exactly that, and it is also impossible to request the first character after the caret position if it is at the start of the document. For both cases getAtIndex() should work.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3071806404

From serb at openjdk.org  Tue Jul 15 04:07:19 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 04:07:19 GMT
Subject: RFR: 8358468: Enhance code consistency: java.desktop/macos [v3]
In-Reply-To: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
References: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
Message-ID: <HmRVUC_Z7JZ9Cn9f5q_BB_1RyAtdqBwqV405U2YE5s4=.aff681a3-7473-4ffa-acfb-6eec95946265@github.com>

> This PR updates the last (!!) remaining platform-specific part of the java.desktop module: macos.
> The unix/windows were previously addressed in: https://github.com/openjdk/jdk/pull/24170 , https://github.com/openjdk/jdk/pull/24941 and https://github.com/openjdk/jdk/pull/25439.
> 
> Note: Unlike on other platforms, the initial change for macOS caused the "BadSerializationTest" to fail. This test relies on internal details of the Aqua Look & Feel that were previously exposed via serialized data (and already [fails](https://bugs.openjdk.org/browse/JDK-8277817) on other platforms). Adding the final modifier to the class changes its serialVersionUID, which triggered the failure even on macOS.
> To avoid this issue, I have reverted the changes to those internal classes for now, see https://github.com/openjdk/jdk/pull/25607/commits/ff7e64b6e38a1a809d434628f304e49408135697
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff -o d.txt && grep -E '^+|^-' d.txt | grep -vE '^+++|^---'
> 
> ====================================================
> 
> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected ...

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

 - Merge branch 'openjdk:master' into over_macos
 - Merge branch 'openjdk:master' into over_macos
 - Fix java/awt/dnd/BadSerializationTest/BadSerializationTest.java test
 - restore formatting
 - final in java.desktop/macos
 - override in java.desktop/macos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25607/files
  - new: https://git.openjdk.org/jdk/pull/25607/files/2ebaf02d..dca9c7ab

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

  Stats: 4677 lines in 139 files changed: 1254 ins; 3071 del; 352 mod
  Patch: https://git.openjdk.org/jdk/pull/25607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25607/head:pull/25607

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

From honkar at openjdk.org  Tue Jul 15 04:35:43 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 15 Jul 2025 04:35:43 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
Message-ID: <p8VZ58TX156rLHowHAxpPlGqAl7N6jOW6JACuzaYszQ=.9bd4da60-a3e3-4725-beef-17a13e5978d5@github.com>

On Fri, 11 Jul 2025 15:47:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
> One of the conformance tests fails on these hosts.
> 
> It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.
> 
> This changeset utilizes the Crtc and Output Randr APIs to change the display mode.
> 
> Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
> This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.
> 
> The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.
> 
> Testing looks good on VNC and local machines.

Fix LGTM.
It works as expected on VNC hosts. No regressions observed with existing java/awt/FullScreen tests on VNC hosts and on local.

src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h line 65:

> 63: };
> 64: 
> 65: #define MAX_DISPLAY_MODES 256

File requires copyright year update

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26268#pullrequestreview-3018514281
PR Review Comment: https://git.openjdk.org/jdk/pull/26268#discussion_r2206302142

From kizune at openjdk.org  Tue Jul 15 04:51:37 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 15 Jul 2025 04:51:37 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
Message-ID: <fY37Gd9lDkrxDaiZ6LoBmNdzGfGxFPgJqtxhn4wibcw=.b1fc9d71-0165-4711-a38a-0a27fe299971@github.com>

On Fri, 11 Jul 2025 15:47:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
> One of the conformance tests fails on these hosts.
> 
> It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.
> 
> This changeset utilizes the Crtc and Output Randr APIs to change the display mode.
> 
> Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
> This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.
> 
> The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.
> 
> Testing looks good on VNC and local machines.

Marked as reviewed by kizune (Reviewer).

Seems reasonable. The only strange thing is that passing boolean parameter, immediately negating it and use the new value everywhere. But that's Ok if it increase the code readability which i think it does.

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

PR Review: https://git.openjdk.org/jdk/pull/26268#pullrequestreview-3018625342
PR Comment: https://git.openjdk.org/jdk/pull/26268#issuecomment-3071904603

From abhiscxk at openjdk.org  Tue Jul 15 05:45:22 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 15 Jul 2025 05:45:22 GMT
Subject: RFR: 8338282: javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java
 test failed on macOS and Ubuntu
Message-ID: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>

Test is failing on intermittently on macOS and ubuntu machine in CI testing.
Test stabilization done by requesting focus for the frame before starting the testing. 

Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
CI link is added in JBS.

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

Commit messages:
 - Test stabilization

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

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

From azvegint at openjdk.org  Tue Jul 15 06:24:45 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 15 Jul 2025 06:24:45 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
Message-ID: <mmtXTC1mz61M256fP-nSDcOMmunc_Cmi4l8HZiZ_8p8=.59758454-d326-40f7-ad1f-5dd2febe4f64@github.com>

On Fri, 11 Jul 2025 15:47:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
> One of the conformance tests fails on these hosts.
> 
> It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.
> 
> This changeset utilizes the Crtc and Output Randr APIs to change the display mode.
> 
> Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
> This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.
> 
> The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.
> 
> Testing looks good on VNC and local machines.

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

PR Review: https://git.openjdk.org/jdk/pull/26268#pullrequestreview-3018818082

From azvegint at openjdk.org  Tue Jul 15 06:24:46 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 15 Jul 2025 06:24:46 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <p8VZ58TX156rLHowHAxpPlGqAl7N6jOW6JACuzaYszQ=.9bd4da60-a3e3-4725-beef-17a13e5978d5@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
 <p8VZ58TX156rLHowHAxpPlGqAl7N6jOW6JACuzaYszQ=.9bd4da60-a3e3-4725-beef-17a13e5978d5@github.com>
Message-ID: <DYcpBWUWQLxZY8RUh-oB3aJyFDFr_kkkjOWo1RqdLqQ=.796532de-8889-4772-8e2d-8461f7f7e503@github.com>

On Tue, 15 Jul 2025 04:32:36 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
>> One of the conformance tests fails on these hosts.
>> 
>> It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.
>> 
>> This changeset utilizes the Crtc and Output Randr APIs to change the display mode.
>> 
>> Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
>> This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.
>> 
>> The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.
>> 
>> Testing looks good on VNC and local machines.
>
> src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h line 65:
> 
>> 63: };
>> 64: 
>> 65: #define MAX_DISPLAY_MODES 256
> 
> File requires copyright year update

It can be handled as a batch copyright year update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26268#discussion_r2206491921

From azvegint at openjdk.org  Tue Jul 15 06:24:46 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 15 Jul 2025 06:24:46 GMT
Subject: Integrated: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
Message-ID: <qgAop8tbz26cudQefFS5rWJE5jfBKWp8-w71c5ymRl0=.1dc2d56d-58dc-4524-895f-0a47725a4a16@github.com>

On Fri, 11 Jul 2025 15:47:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
> One of the conformance tests fails on these hosts.
> 
> It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.
> 
> This changeset utilizes the Crtc and Output Randr APIs to change the display mode.
> 
> Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
> This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.
> 
> The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.
> 
> Testing looks good on VNC and local machines.

This pull request has now been integrated.

Changeset: 18c2e40d
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18c2e40de75f974858aeb453892e4c7c8d5aa90e
Stats:     354 lines in 3 files changed: 346 ins; 1 del; 7 mod

8354415: [Ubuntu25.04] api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode - setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc

Reviewed-by: honkar, kizune

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

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

From serb at openjdk.org  Tue Jul 15 06:32:47 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 06:32:47 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
Message-ID: <ptvTHtS01Fab2B6m9PONtAyKdLfDtaC5X8EyE3MmvAw=.23f3c575-312c-4a52-b392-41a0b5c2c46f@github.com>

On Fri, 11 Jul 2025 15:47:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
> One of the conformance tests fails on these hosts.
> 
> It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.
> 
> This changeset utilizes the Crtc and Output Randr APIs to change the display mode.
> 
> Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
> This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.
> 
> The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.
> 
> Testing looks good on VNC and local machines.

src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java line 354:

> 352:         if (xrandrExtSupported == null) {
> 353:             boolean useOldConfigDisplayMode =
> 354:                     Boolean.getBoolean("awt.x11useOldConfigDisplayMode");

i guess the idea of this property is to share it to the ppl as a workaround in case some errors will occur? Then the CSR might be needed for it. The better name might be: "awt.x11.EnableXrandrDisplayModes"=true.

src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 1753:

> 1751: static jint refreshRateFromModeInfo(const XRRModeInfo *modeInfo) {
> 1752:     if (!modeInfo->hTotal || !modeInfo->vTotal) {
> 1753:         return 0;

It should be REFRESH_RATE_UNKNOWN?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26268#discussion_r2206517949
PR Review Comment: https://git.openjdk.org/jdk/pull/26268#discussion_r2206522445

From serb at openjdk.org  Tue Jul 15 06:44:43 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 06:44:43 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
Message-ID: <Ivye_KdHK0GkcazOfQjvx6sMxlhWJhGI5qn0Mll73oI=.072829ab-f9e6-48f3-a5ff-7759795b4f4e@github.com>

On Fri, 11 Jul 2025 15:47:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
> One of the conformance tests fails on these hosts.
> 
> It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.
> 
> This changeset utilizes the Crtc and Output Randr APIs to change the display mode.
> 
> Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
> This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.
> 
> The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.
> 
> Testing looks good on VNC and local machines.

src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c line 1986:

> 1984:         Bool matchH = (isLandscape ? mode.height : mode.width) == (unsigned int) height;
> 1985: 
> 1986:         if (matchW && matchH && rr == refreshRate) {

do we need to stop on the first mode we found or we should select the nearest refrate to the int? or maybe select the largest one? like 59.7 vs 59.9 vs 60?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26268#discussion_r2206543463

From duke at openjdk.org  Tue Jul 15 08:29:47 2025
From: duke at openjdk.org (Dmitry Kulikov)
Date: Tue, 15 Jul 2025 08:29:47 GMT
Subject: RFR: 8360120: Bundled macOS applications not receiving OpenURL
 events when launched as subprocess [v2]
In-Reply-To: <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com>
References: <uWgL0eCGLxkGigE-IPkEgbq2i3t-dHmAyyPmedZrgFA=.8ff131f6-bc00-4a1e-ada2-99346bae1220@github.com>
 <7lKxbQNDcM9CZ2cM1XfnoMeeRLltiFkju6U3wPk71OA=.78b110f4-cb40-461c-aa3f-5f3bbacb2ae0@github.com>
Message-ID: <GlWfv9MR2BwW9OQ21KANvcX1tRqBVMLI7XUkYI_36vs=.49f772f4-04fd-4f07-8a6e-0683eed4c574@github.com>

On Wed, 25 Jun 2025 07:03:33 GMT, Dmitry Kulikov <duke at openjdk.org> wrote:

>> Added an on-demand installation of the native OpenURL event handler to the `Application.setOpenURIHandler()`.
>> 
>> This does not break the specification for the affected API, since the requirement of the application being bundled and containing `CFBundleURLTypes` in the `Info.plist` is still valid: macOS will neither launch nor send OpenURL events to an application that does not declare such capabilities it the bundle.
>> 
>> Running tests on macOS showed no regressions after this patch. Other platforms are not affected.
>
> Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

Yes, all 3 points are correct. Probably the native URL handler is installed during the startup of the bundled application in order to catch the first OpenURL event that might have launched the application in the first place (I'll conduct more tests to see how an early handler registration affects the startup behavior). Java code technically is not required to install any URL handlers even in case of a bundled application, however declaring the capability to handle OpenURL events in the application bundle requires some actions from the application developer. I guess it was thought of as a "common sense" not to declare OpenURL handling capability in the bundle without actually handling the URLs in the Java code.

Searching the Internet so far did not show up any references to `[bundle _hasEAWTOverride:@"URLHandler"]` (or the respective keys in the property list file) except the JDK code itself. Under such circumstances I've decided to leave these checks intact.

I'm investigating the possibility of composing a regression test for this change. It does not look straight impossible so far. I'll post an update on this matter shortly.

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

PR Comment: https://git.openjdk.org/jdk/pull/25967#issuecomment-3072648383

From asemenov at openjdk.org  Tue Jul 15 08:33:39 2025
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 15 Jul 2025 08:33:39 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v4]
In-Reply-To: <PxraFDnGTaBbv8TKEkJYLR97I95Whzhmf8oWXb9f4bc=.fde406a7-7736-4fa7-a820-d3ff80b96c44@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <PxraFDnGTaBbv8TKEkJYLR97I95Whzhmf8oWXb9f4bc=.fde406a7-7736-4fa7-a820-d3ff80b96c44@github.com>
Message-ID: <m1laPcCdYREDQvUXvhsIhfe5mvEi25u2qJf6yFMBLog=.dcde0477-c427-4850-820f-273c0fefa0a8@github.com>

On Mon, 14 Jul 2025 08:36:57 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> **Issue** : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
>> 
>> **Analysis** : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
>> 
>> **Proposed Fix** : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.
>> 
>> **Testing** : Manual test case has been added to verify the fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Role description code moved to TabButtonAccessibility

LGTM

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

Marked as reviewed by asemenov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26096#pullrequestreview-3019303145

From duke at openjdk.org  Tue Jul 15 10:24:49 2025
From: duke at openjdk.org (Nikita Provotorov)
Date: Tue, 15 Jul 2025 10:24:49 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
 <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
Message-ID: <Q_xJMrfckW-EbvxPV190rheVTtAYv5GaRKYjQo_80nU=.01aaa049-8aa7-42ef-95cd-abb71c8b603e@github.com>

On Tue, 15 Jul 2025 03:58:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I modified Abhishek's test:
>> 
>> 
>>             System.out.println(" i  bef   at  aft");
>>             for (int i : new int[] {0, 1, 2, 8, 9, 10}) {
>>                 System.out.printf("%2d%5s%5s%5s\n",
>>                                   i,
>>                                   at.getBeforeIndex(CHARACTER, i),
>>                                   at.getAtIndex(CHARACTER, i),
>>                                   at.getAfterIndex(CHARACTER, i));
>>             }
>> 
>> 
>> This way, I created a table of returned values:
>> 
>> 
>> Text: "0123456789"
>> Text Length: 10
>>  i  bef   at  aft
>>  0 null    0    1
>>  1    0    1    2
>>  2    1    2    3
>>  8    7    8    9
>>  9    8    9 null
>> 10 null null null
>> 
>> 
>> I'd expect to see 9 as the return value of `getBeforeIndex` for the index of 10. This would make the table symmetrical.
>> 
>> Therefore, I'm in favour for Abhishek's proposed fix.
>> 
>> ---
>> 
>> The description of the methods in `AccessibleText` is vague. None of the three methods specifies what the index means and what values are accepted for it.
>> 
>> According to the text model, index 10 is still valid, it's the index between the last character and the implied line break, so `tf.getDocument().getText(10, 1)` returns `\n`.
>> 
>> Having this in mind, the specification of the `getBeforeIndex`, `getAtIndex`, `getAfterIndex` methods should be updated to *explicitly specify the valid values for the `index` parameter*.
>
>>I'd expect to see 9 as the return value of getBeforeIndex for the index of 10. This would make the table symmetrical.
> 
> Why do you expect that? The spec states that the index should be "an index within the text." That index is also used in other methods, such as getCharacterBounds(), etc. If we fixed it only for text at the end, it would make the behavior even less symmetric, since for a negative value, the model will always throw an exception.
> 
>>According to the text model, index 10 is still valid, it's the index between the last character and the implied line break, so tf.getDocument().getText(10, 1) returns \n.
> 
> The last character is implementation detail, it is not part of the "users data" this is the reason why it is excluded from the Document.getLength(). So passing length as a last character might cause an exception for custom documents. We also have the getCharCount() methods which returns "the number of characters (valid indices)".
> 
> Also, why are we only talking about JTextComponent? There are other same implementations of AccessibleText for example [JLabel](https://github.com/openjdk/jdk/blob/0acd065bf5a75090b84c28b28856a62d86c52791/src/java.desktop/share/classes/javax/swing/JLabel.java#L1287).
> 
>>Here i disagree, the "within the text" does not imply that the position behind the last character is not within the text. Otherwise with the caret is at the end of the text it is impossible to request last word or character before the caret position which is one of the valid use cases of this accessibility method. I think the fix is valid.
> 
> It means exactly that, and it is also impossible to request the first character after the caret position if it is at the start of the document. For both cases getAtIndex() should work.

I agree with @mrserb: there already is `getAtIndex` and the documentation is clear about that the index should be within the text. From my side I'd add that changing this behavior may break backward-compatibility with client's custom AWT/Swing components.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3073048371

From prr at openjdk.org  Tue Jul 15 19:34:48 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Jul 2025 19:34:48 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v33]
In-Reply-To: <jm4TovrGJTt7MZyM2ukXGPAwepasvagsG8GJNI3xdRQ=.d0415c97-19ef-404c-b05f-e9cbfcf087a2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>
 <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
 <icKQrBbjRkYWpZ6_bvPYUzAxHIsH-a4iQP510lHj6TU=.72699793-dacc-4cbc-8bc6-4fec98745f4e@github.com>
 <jm4TovrGJTt7MZyM2ukXGPAwepasvagsG8GJNI3xdRQ=.d0415c97-19ef-404c-b05f-e9cbfcf087a2@github.com>
Message-ID: <B-4hUR1yQlOm6Dfz8ealK9po51qIJtqJkBDBzH1pdrU=.16b01ebc-a132-46d9-be7a-89273d7f9c92@github.com>

On Mon, 14 Jul 2025 05:16:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Shouldn't Windows 10 do it the new way too ?
> 
> I didn't intentionally change the design for Windows 10 as that was the behaviour which was in existence (even though by "accident" as we learnt) for so long our JDK code for Windows L&F is in existence, and some user might see the change (if we make Windows 11 and 10 same) and find it abrupt and not in sync to whatever they were seeing and "used to" till now
> 
> Also, there was no issue raised for Windows 10 about this behaviour so I believe it was same with native app. Also, Windows 10 I believe is in its last leg and probable EOL in few months so thought of not changing the behaviour at this last moment. Finally, any change to Windows 10 design will require extensive testing and I didn't have any Windows10 system so would have to rely on others and it would have been hard to replicate and fix if reported by others.

No issue was raised because no one knew any better. Now we know.
I realise that it is a little more work for you but I think it is the right thing to do and will make the code easier to maintain and test, not harder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2208482989

From achung at openjdk.org  Tue Jul 15 19:54:39 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 15 Jul 2025 19:54:39 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux
In-Reply-To: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
Message-ID: <6rkJv8BuGgrA2L7AQ-gXfvqcRqADHLgZaq9PC3aGZ8w=.64ff2902-b225-4c08-840c-6277b64b40c2@github.com>

On Mon, 14 Jul 2025 17:00:35 GMT, Anass Baya <abaya at openjdk.org> wrote:

> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.

What's causing the recursive re-entry? Is the bug in the code path in linux when calling getFocusableWindowState?

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

PR Comment: https://git.openjdk.org/jdk/pull/26298#issuecomment-3075300527

From prr at openjdk.org  Tue Jul 15 20:09:55 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Jul 2025 20:09:55 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
Message-ID: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>

Eliminate a finalize() method in the Swing macOS implementation.

I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)

import javax.swing.JTabbedPane;
import javax.swing.plaf.TabbedPaneUI;

public class CreateTabbedPaneUIStressTest {

   public static void main(String[] args) {
       for (int i=0; i<1000000000; i++) {
           JTabbedPane jtp = new JTabbedPane();
           TabbedPaneUI tpui = jtp.getUI();
       }
   }
}


I also monitored the process size using 'top'.
And when I commented out the native call that did the free and re-tested I saw process size grow.

Turning the above into a useful regression test doesn't seem possible to me.
Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.

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

Commit messages:
 - 8362289
 - 8362289

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

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

From prr at openjdk.org  Tue Jul 15 20:09:56 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Jul 2025 20:09:56 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
In-Reply-To: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
Message-ID: <_mAKSvrNI_HDh04AtS5bZAB8RE8FgcaVGcYpDQrQ7W4=.7fc90a57-e8a0-4ed7-b4cf-a720781a2d65@github.com>

On Tue, 15 Jul 2025 19:57:56 GMT, Phil Race <prr at openjdk.org> wrote:

> Eliminate a finalize() method in the Swing macOS implementation.
> 
> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
> 
> import javax.swing.JTabbedPane;
> import javax.swing.plaf.TabbedPaneUI;
> 
> public class CreateTabbedPaneUIStressTest {
> 
>    public static void main(String[] args) {
>        for (int i=0; i<1000000000; i++) {
>            JTabbedPane jtp = new JTabbedPane();
>            TabbedPaneUI tpui = jtp.getUI();
>        }
>    }
> }
> 
> 
> I also monitored the process size using 'top'.
> And when I commented out the native call that did the free and re-tested I saw process size grow.
> 
> Turning the above into a useful regression test doesn't seem possible to me.
> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.

src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 130:

> 128: 
> 129:         public synchronized void dispose() {
> 130:             if (cfDictionaryPtr == 0) {

although the constructor throws an exception if it can't initialize this and also the native method checks for 0 too,
I decided to leave this existing check out of an abundance of caution.
It ensures that the method is safe to be called twice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2208550170

From serb at openjdk.org  Tue Jul 15 20:27:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 20:27:39 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
In-Reply-To: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
Message-ID: <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>

On Tue, 15 Jul 2025 19:57:56 GMT, Phil Race <prr at openjdk.org> wrote:

> Eliminate a finalize() method in the Swing macOS implementation.
> 
> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
> 
> import javax.swing.JTabbedPane;
> import javax.swing.plaf.TabbedPaneUI;
> 
> public class CreateTabbedPaneUIStressTest {
> 
>    public static void main(String[] args) {
>        for (int i=0; i<1000000000; i++) {
>            JTabbedPane jtp = new JTabbedPane();
>            TabbedPaneUI tpui = jtp.getUI();
>        }
>    }
> }
> 
> 
> I also monitored the process size using 'top'.
> And when I commented out the native call that did the free and re-tested I saw process size grow.
> 
> Turning the above into a useful regression test doesn't seem possible to me.
> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.

src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 115:

> 113:         flipped = other.flipped;
> 114:         cfDictionaryPtr = getCFDictionary(flipped);
> 115:         if (cfDictionaryPtr == 0) throw new RuntimeException("Unable to create native representation");

Just a side topic to discuss: In the past I tried to look into this pattern and figure out is it possible for the GC to start cleaning the object after we allocate the native resource but before we register it with Disposer.addRecord. In such a case, the cleanup might never be executed.

Perhaps we should consider adding a reachabilityFence at the end of Disposer.addRecord, for both the DisposerRecord and the referent, to ensure they remain reachable. Similarly how it was done for cleaner:
https://hg.openjdk.org/jdk9/jdk9/jdk/rev/1f33e517236e
Or may be we can just use cleaner.

src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 138:

> 136:             }
> 137:             cfDictionaryPtr = 0;
> 138:         }

Is it possible for this method to be called twice? It seems that not all other implementations include the ptr != 0 guard.

Also, synchronization appears to be used on the wrong object. I believe it should be synchronized on the outer JRSUIControl class, which uses synchronization to access the cfDictionaryPtr field. Alternatively, we might consider implementing synchronization in a different way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2208586134
PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2208586380

From serb at openjdk.org  Tue Jul 15 20:32:46 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 20:32:46 GMT
Subject: Integrated: 8358468: Enhance code consistency: java.desktop/macos
In-Reply-To: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
References: <twvjhTOH-1vR5h0xlwvGDSOUF_IHoeIupyS1AMvxvjI=.f8a0430e-6917-4471-a954-168631653721@github.com>
Message-ID: <f35YBO_YRlCS5V_TmXn5nNAForkIAlTLuFBVCgowp4g=.dceec77e-5458-4ed6-9109-1f23f28162e8@github.com>

On Tue, 3 Jun 2025 06:38:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This PR updates the last (!!) remaining platform-specific part of the java.desktop module: macos.
> The unix/windows were previously addressed in: https://github.com/openjdk/jdk/pull/24170 , https://github.com/openjdk/jdk/pull/24941 and https://github.com/openjdk/jdk/pull/25439.
> 
> Note: Unlike on other platforms, the initial change for macOS caused the "BadSerializationTest" to fail. This test relies on internal details of the Aqua Look & Feel that were previously exposed via serialized data (and already [fails](https://bugs.openjdk.org/browse/JDK-8277817) on other platforms). Adding the final modifier to the class changes its serialVersionUID, which triggered the failure even on macOS.
> To avoid this issue, I have reverted the changes to those internal classes for now, see https://github.com/openjdk/jdk/pull/25607/commits/ff7e64b6e38a1a809d434628f304e49408135697
> 
> To download the diff file and filter only the modified lines you can use the following script:
> 
> 
> curl -s https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff -o d.txt && grep -E '^+|^-' d.txt | grep -vE '^+++|^---'
> 
> ====================================================
> 
> The `java.desktop` module currently lacks proper use of the `@Override` annotation for methods and the `final` modifier for classes. While similar changes were previously made in the [JavaSound](https://github.com/openjdk/jdk/commit/e0c7d59246cf36644d494eced76e4b9d96ff1ded#diff-ae3e5f9c40fe25ef03e7a89844de174ef5c15e6179d769e2a4bcb7e73688c9b5), [java.desktop/windows](https://github.com/openjdk/jdk/pull/24170) (and some of the classes on demand), these changes are not as critical now due to the new jdk "encapsulation", but they are still useful for improving code consistency.
> 
> The public API was not affected so there is no need to worry about a CSR
> 
> Note: I will submit additional patches in this area later because:
> 
> 1. Only lines with `@Override` and `final` were modified to keep the diff clear - header dates were not updated (that could be covered by one patch similar to [this](https://bugs.openjdk.org/browse/JDK-8345797))
> 2. I skipped adding `@Override` for anonymous classes
> 
> Any feedback or suggestions are welcome!
> 
> Here is a [link](https://patch-diff.githubusercontent.com/raw/openjdk/jdk/pull/25607.diff) to a simple diff file, it might be more convenient for reviewing the changes.
> 
> The build was successful, and I ran all the open jtreg tests without issues. But it's possible that some closed tests may be affected ...

This pull request has now been integrated.

Changeset: 6fc032de
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6fc032de2c19853f3fa4f57659dc8559b516d7c5
Stats:     1216 lines in 169 files changed: 859 ins; 0 del; 357 mod

8358468: Enhance code consistency: java.desktop/macos

Reviewed-by: prr, azvegint

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

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

From prr at openjdk.org  Tue Jul 15 20:47:14 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Jul 2025 20:47:14 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java
Message-ID: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>

Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.

I don't see a way to add a test to verify this clean up.

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

Commit messages:
 - 8362291

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

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

From serb at openjdk.org  Tue Jul 15 21:17:41 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 21:17:41 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java
In-Reply-To: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
Message-ID: <MVY6_1ZmemQFZtt-qmwrQu9qIljfICRHkXi3sthDfcg=.0ada8873-6f95-443c-911f-789e1e91dca0@github.com>

On Tue, 15 Jul 2025 20:42:15 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
> 
> I don't see a way to add a test to verify this clean up.

src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 153:

> 151:         }
> 152: 
> 153:         public synchronized void dispose() {

Why the method is synchronized? we can call it on a different threads via Disposer?

src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 154:

> 152: 
> 153:         public synchronized void dispose() {
> 154:             if (displayReconfigContext != 0L) {

can it be 0 here? it seems we never register 0 pointer, and we have a guard in native to be safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2208694333
PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2208693159

From serb at openjdk.org  Tue Jul 15 21:28:40 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 21:28:40 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu
In-Reply-To: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
Message-ID: <1Atd4cmRPDSm4zyAOz4RSecKHUZ6AT3DP538xmKVzCI=.d8d0e1a6-a2b1-434c-abb1-1001c620206b@github.com>

On Tue, 15 Jul 2025 05:40:17 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
> Test stabilization done by requesting focus for the frame before starting the testing. 
> 
> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
> CI link is added in JBS.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26307#pullrequestreview-3022381143

From serb at openjdk.org  Tue Jul 15 21:45:41 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Jul 2025 21:45:41 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
In-Reply-To: <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
Message-ID: <KOPJ6k4qDUFYdIBJrExPysmQYPyZHtO81yLlvwjyaUo=.95b5527e-403e-4274-8aa6-3b4b95062c63@github.com>

On Tue, 15 Jul 2025 20:24:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Eliminate a finalize() method in the Swing macOS implementation.
>> 
>> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
>> 
>> import javax.swing.JTabbedPane;
>> import javax.swing.plaf.TabbedPaneUI;
>> 
>> public class CreateTabbedPaneUIStressTest {
>> 
>>    public static void main(String[] args) {
>>        for (int i=0; i<1000000000; i++) {
>>            JTabbedPane jtp = new JTabbedPane();
>>            TabbedPaneUI tpui = jtp.getUI();
>>        }
>>    }
>> }
>> 
>> 
>> I also monitored the process size using 'top'.
>> And when I commented out the native call that did the free and re-tested I saw process size grow.
>> 
>> Turning the above into a useful regression test doesn't seem possible to me.
>> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.
>
> src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 115:
> 
>> 113:         flipped = other.flipped;
>> 114:         cfDictionaryPtr = getCFDictionary(flipped);
>> 115:         if (cfDictionaryPtr == 0) throw new RuntimeException("Unable to create native representation");
> 
> Just a side topic to discuss: In the past I tried to look into this pattern and figure out is it possible for the GC to start cleaning the object after we allocate the native resource but before we register it with Disposer.addRecord. In such a case, the cleanup might never be executed.
> 
> Perhaps we should consider adding a reachabilityFence at the end of Disposer.addRecord, for both the DisposerRecord and the referent, to ensure they remain reachable. Similarly how it was done for cleaner:
> https://hg.openjdk.org/jdk9/jdk9/jdk/rev/1f33e517236e
> Or may be we can just use cleaner.

there is even a bug for Cleaner that the reachabilityFence should be moved to the end of register:
https://bugs.openjdk.org/browse/JDK-8291867
If there are no objectiosn I'll add it to the Disposer.addRecord in a separate bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2208767482

From prr at openjdk.org  Tue Jul 15 22:36:38 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Jul 2025 22:36:38 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
In-Reply-To: <KOPJ6k4qDUFYdIBJrExPysmQYPyZHtO81yLlvwjyaUo=.95b5527e-403e-4274-8aa6-3b4b95062c63@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <KOPJ6k4qDUFYdIBJrExPysmQYPyZHtO81yLlvwjyaUo=.95b5527e-403e-4274-8aa6-3b4b95062c63@github.com>
Message-ID: <W5AhemC_BCQ6emEIzYH-evy1gzqHdT0cu6nQtkLVc-4=.148b59e9-2032-4282-9955-8e45a56f5f9f@github.com>

On Tue, 15 Jul 2025 21:43:04 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 115:
>> 
>>> 113:         flipped = other.flipped;
>>> 114:         cfDictionaryPtr = getCFDictionary(flipped);
>>> 115:         if (cfDictionaryPtr == 0) throw new RuntimeException("Unable to create native representation");
>> 
>> Just a side topic to discuss: In the past I tried to look into this pattern and figure out is it possible for the GC to start cleaning the object after we allocate the native resource but before we register it with Disposer.addRecord. In such a case, the cleanup might never be executed.
>> 
>> Perhaps we should consider adding a reachabilityFence at the end of Disposer.addRecord, for both the DisposerRecord and the referent, to ensure they remain reachable. Similarly how it was done for cleaner:
>> https://hg.openjdk.org/jdk9/jdk9/jdk/rev/1f33e517236e
>> Or may be we can just use cleaner.
>
> there is even a bug for Cleaner that the reachabilityFence should be moved to the end of register:
> https://bugs.openjdk.org/browse/JDK-8291867
> If there are no objectiosn I'll add it to the Disposer.addRecord in a separate bug.

I think that would be OK, meaning probably harmless. But I don't know if this case actually requires it.
Where I've seen a problem like this a Java object is used at an earlier point in the method and not again and so becomes eligible to be freed, but some native resource it held is needed later but is already freed along with its no longer references holder.

Here, if this object (the JRSUIControl) becomes unreachable during construction, and so the referent and disposer are also unreachable outside this object, they are still going to be live until we reach code in the constructor which uses them and since  the referent and the disposer are passed into addRecord they'll be live there until stored.

But these cases are subtle, maybe I'm missing something. Can you expand on the scenario ?
Or maybe there's some other patterns where we use Disposer that it is needed ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2208837967

From prr at openjdk.org  Tue Jul 15 22:40:39 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Jul 2025 22:40:39 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
In-Reply-To: <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
Message-ID: <G7ZYGfikLqwjkUUnoTW0nbamkrBrPjhVn4R07JWRMKY=.06dc0dfe-01ca-4279-9e60-fc2bdb1d48dd@github.com>

On Tue, 15 Jul 2025 20:24:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Eliminate a finalize() method in the Swing macOS implementation.
>> 
>> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
>> 
>> import javax.swing.JTabbedPane;
>> import javax.swing.plaf.TabbedPaneUI;
>> 
>> public class CreateTabbedPaneUIStressTest {
>> 
>>    public static void main(String[] args) {
>>        for (int i=0; i<1000000000; i++) {
>>            JTabbedPane jtp = new JTabbedPane();
>>            TabbedPaneUI tpui = jtp.getUI();
>>        }
>>    }
>> }
>> 
>> 
>> I also monitored the process size using 'top'.
>> And when I commented out the native call that did the free and re-tested I saw process size grow.
>> 
>> Turning the above into a useful regression test doesn't seem possible to me.
>> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.
>
> src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 138:
> 
>> 136:             }
>> 137:             cfDictionaryPtr = 0;
>> 138:         }
> 
> Is it possible for this method to be called twice? It seems that not all other implementations include the ptr != 0 guard.
> 
> Also, synchronization appears to be used on the wrong object. I believe it should be synchronized on the outer JRSUIControl class, which uses synchronization to access the cfDictionaryPtr field. Alternatively, we might consider implementing synchronization in a different way.

I am not *expecting* it to be called twice. I'm just saying that with this check it would be safe if it were.
Not sure I even need synchronization here. Only the Disposer will have a reference.
So I could remove synchronized, remove the != 0 check  ... but I don't see a problem either way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2208841918

From prr at openjdk.org  Tue Jul 15 22:42:39 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Jul 2025 22:42:39 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java
In-Reply-To: <MVY6_1ZmemQFZtt-qmwrQu9qIljfICRHkXi3sthDfcg=.0ada8873-6f95-443c-911f-789e1e91dca0@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <MVY6_1ZmemQFZtt-qmwrQu9qIljfICRHkXi3sthDfcg=.0ada8873-6f95-443c-911f-789e1e91dca0@github.com>
Message-ID: <y7_BhMRnV26x8_Y3JFF6JteS-ymYJm352a1zIetuHoQ=.231e78eb-f6b1-4c45-a5df-73352f2a3dd2@github.com>

On Tue, 15 Jul 2025 21:14:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
>> 
>> I don't see a way to add a test to verify this clean up.
>
> src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 153:
> 
>> 151:         }
>> 152: 
>> 153:         public synchronized void dispose() {
> 
> Why the method is synchronized? we can call it on a different threads via Disposer?

It doesn't have to be. Is it a problem that it is ?

> src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 154:
> 
>> 152: 
>> 153:         public synchronized void dispose() {
>> 154:             if (displayReconfigContext != 0L) {
> 
> can it be 0 here? it seems we never register 0 pointer, and we have a guard in native to be safe.

and is there any harm in the check ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2208843438
PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2208843774

From serb at openjdk.org  Wed Jul 16 00:12:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Jul 2025 00:12:38 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java
In-Reply-To: <y7_BhMRnV26x8_Y3JFF6JteS-ymYJm352a1zIetuHoQ=.231e78eb-f6b1-4c45-a5df-73352f2a3dd2@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <MVY6_1ZmemQFZtt-qmwrQu9qIljfICRHkXi3sthDfcg=.0ada8873-6f95-443c-911f-789e1e91dca0@github.com>
 <y7_BhMRnV26x8_Y3JFF6JteS-ymYJm352a1zIetuHoQ=.231e78eb-f6b1-4c45-a5df-73352f2a3dd2@github.com>
Message-ID: <YkRM74J21Mt7KGVB-s-oL1MZqrRv1PmUPZmwH31oYQY=.521bd7ee-aa6d-44b2-b7be-7532adb5d6e4@github.com>

On Tue, 15 Jul 2025 22:39:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 153:
>> 
>>> 151:         }
>>> 152: 
>>> 153:         public synchronized void dispose() {
>> 
>> Why the method is synchronized? we can call it on a different threads via Disposer?
>
> It doesn't have to be. Is it a problem that it is ?

Yeah, if it does not need to be, we can skip it; otherwise, we can update all existing implementations to follow the same pattern.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2208933608

From serb at openjdk.org  Wed Jul 16 00:13:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Jul 2025 00:13:39 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
In-Reply-To: <G7ZYGfikLqwjkUUnoTW0nbamkrBrPjhVn4R07JWRMKY=.06dc0dfe-01ca-4279-9e60-fc2bdb1d48dd@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <G7ZYGfikLqwjkUUnoTW0nbamkrBrPjhVn4R07JWRMKY=.06dc0dfe-01ca-4279-9e60-fc2bdb1d48dd@github.com>
Message-ID: <kjWS4HjWniyPaP-NFaOPy0AiuWbOKb2_WliKRh-KY3U=.916e2bd3-7086-4299-aa9f-48342db385ee@github.com>

On Tue, 15 Jul 2025 22:38:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 138:
>> 
>>> 136:             }
>>> 137:             cfDictionaryPtr = 0;
>>> 138:         }
>> 
>> Is it possible for this method to be called twice? It seems that not all other implementations include the ptr != 0 guard.
>> 
>> Also, synchronization appears to be used on the wrong object. I believe it should be synchronized on the outer JRSUIControl class, which uses synchronization to access the cfDictionaryPtr field. Alternatively, we might consider implementing synchronization in a different way.
>
> I am not *expecting* it to be called twice. I'm just saying that with this check it would be safe if it were.
> Not sure I even need synchronization here. Only the Disposer will have a reference.
> So I could remove synchronized, remove the != 0 check  ... but I don't see a problem either way.

That would be great if we could drop all unneeded code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2208934516

From serb at openjdk.org  Wed Jul 16 02:03:46 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Jul 2025 02:03:46 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
In-Reply-To: <W5AhemC_BCQ6emEIzYH-evy1gzqHdT0cu6nQtkLVc-4=.148b59e9-2032-4282-9955-8e45a56f5f9f@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <KOPJ6k4qDUFYdIBJrExPysmQYPyZHtO81yLlvwjyaUo=.95b5527e-403e-4274-8aa6-3b4b95062c63@github.com>
 <W5AhemC_BCQ6emEIzYH-evy1gzqHdT0cu6nQtkLVc-4=.148b59e9-2032-4282-9955-8e45a56f5f9f@github.com>
Message-ID: <wh5FY46Jdi_keoyVDm6lg4SKBi165YSM_Yk4_Ybe5fU=.2b827f8d-cf16-4163-9588-64fdacbc3706@github.com>

On Tue, 15 Jul 2025 22:34:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> there is even a bug for Cleaner that the reachabilityFence should be moved to the end of register:
>> https://bugs.openjdk.org/browse/JDK-8291867
>> If there are no objectiosn I'll add it to the Disposer.addRecord in a separate bug.
>
> I think that would be OK, meaning probably harmless. But I don't know if this case actually requires it.
> Where I've seen a problem like this a Java object is used at an earlier point in the method and not again and so becomes eligible to be freed, but some native resource it held is needed later but is already freed along with its no longer references holder.
> 
> Here, if this object (the JRSUIControl) becomes unreachable during construction, and so the referent and disposer are also unreachable outside this object, they are still going to be live until we reach code in the constructor which uses them and since  the referent and the disposer are passed into addRecord they'll be live there until stored.
> 
> But these cases are subtle, maybe I'm missing something. Can you expand on the scenario ?
> Or maybe there's some other patterns where we use Disposer that it is needed ?

I think I understand why reachabilityFence is used [here](https://github.com/openjdk/jdk/blob/a5c9bc70324693e9d0b25bb2c51b91dfc750c453/src/java.base/share/classes/jdk/internal/ref/PhantomCleanable.java#L84). That code first registers the object in the cleanup queue and then continues executing the rest of the constructor. As far as I understand, the object could be collected between the registration and the end of the constructor so the cleaner will be called on a partially constructed object.

If that assumption is correct then in the change above the code:
        nativeMap = new HashMap<Key, DoubleValue>();
        changes = new HashMap<Key, DoubleValue>();
might never be executed and the native disposer will be called before, not an issue in this particular case but good to know.
Or I missing something.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2209047550

From bchristi at openjdk.org  Wed Jul 16 03:55:40 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 16 Jul 2025 03:55:40 GMT
Subject: [jdk25] RFR: Merge 121f5a72e4c23919b3a3b474cc3f1ac29ec611af
Message-ID: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>

This brings in cpu25_07 changes.

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

Commit messages:
 - 8360147: Better Glyph drawing redux
 - 8355884: [macos] java/awt/Frame/I18NTitle.java fails on MacOS
 - 8350991: Improve HTTP client header handling
 - 8349594: Enhance TLS protocol support
 - 8349584: Improve compiler processing
 - 8349111: Enhance Swing supports
 - 8348989: Better Glyph drawing
 - 8349551: Failures in tests after JDK-8345625
 - 8345625: Better HTTP connections

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/26340/files
  Stats: 358 lines in 21 files changed: 275 ins; 24 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/26340.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26340/head:pull/26340

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

From jpai at openjdk.org  Wed Jul 16 03:55:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 16 Jul 2025 03:55:41 GMT
Subject: [jdk25] RFR: Merge 121f5a72e4c23919b3a3b474cc3f1ac29ec611af
In-Reply-To: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
References: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
Message-ID: <nvn1ZliZRR8fplYKXC38vFilKzhXAmycocPnIBxDDBw=.7bc6cab6-fc78-41bf-ad9a-86cdbc31203f@github.com>

On Wed, 16 Jul 2025 03:40:43 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu25_07 changes.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26340#pullrequestreview-3023001849

From bchristi at openjdk.org  Wed Jul 16 04:01:42 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 16 Jul 2025 04:01:42 GMT
Subject: [jdk25] RFR: Merge 121f5a72e4c23919b3a3b474cc3f1ac29ec611af [v2]
In-Reply-To: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
References: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
Message-ID: <nH6hdD3c0GqgCzQxqgSM_robxNcIlvyRkT0leb2wn78=.8a5a29bc-30c1-4d4d-82b6-38192a31382a@github.com>

> This brings in cpu25_07 changes.

Brent Christian 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26340/files
  - new: https://git.openjdk.org/jdk/pull/26340/files/121f5a72..121f5a72

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

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

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

From bchristi at openjdk.org  Wed Jul 16 04:01:43 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 16 Jul 2025 04:01:43 GMT
Subject: [jdk25] Integrated: Merge 121f5a72e4c23919b3a3b474cc3f1ac29ec611af
In-Reply-To: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
References: <PVaD2yAiZN3ODagNtvTnnEcwaXluJGhZN6ZEAGw3ta0=.48f0bcc6-6587-42d8-b221-9786564153ba@github.com>
Message-ID: <emulA1MVUDYTK86j2qQxYLyNQMZIpNWh_hMCkD-6CiI=.856646b1-9e5a-414e-9ff4-a4db440a5c44@github.com>

On Wed, 16 Jul 2025 03:40:43 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This brings in cpu25_07 changes.

This pull request has now been integrated.

Changeset: 0e6bf005
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e6bf0055057fae844748a300551549553f59f03
Stats:     358 lines in 21 files changed: 275 ins; 24 del; 59 mod

Merge

Reviewed-by: jpai

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

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

From psadhukhan at openjdk.org  Wed Jul 16 04:42:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 16 Jul 2025 04:42:51 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v33]
In-Reply-To: <B-4hUR1yQlOm6Dfz8ealK9po51qIJtqJkBDBzH1pdrU=.16b01ebc-a132-46d9-be7a-89273d7f9c92@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <XRdjRI4QbK_KcZ75eG-0FXBKlB0eSYly3YcRrHewqC4=.3aac49f4-c046-43bd-ac13-09f571357f39@github.com>
 <5KFKtV8oX5Jdy2fDNINDHBNo5v8CYUmMaeWMiKfJ8Lc=.f1a1b66d-481e-4301-ae4d-6cbbc9672fa0@github.com>
 <icKQrBbjRkYWpZ6_bvPYUzAxHIsH-a4iQP510lHj6TU=.72699793-dacc-4cbc-8bc6-4fec98745f4e@github.com>
 <jm4TovrGJTt7MZyM2ukXGPAwepasvagsG8GJNI3xdRQ=.d0415c97-19ef-404c-b05f-e9cbfcf087a2@github.com>
 <B-4hUR1yQlOm6Dfz8ealK9po51qIJtqJkBDBzH1pdrU=.16b01ebc-a132-46d9-be7a-89273d7f9c92@github.com>
Message-ID: <kgRv0jTRmg1N8-3x1lDaPMeIrWNV9OTUt1MumDkwjB8=.cf878d67-de50-4b52-9e0a-df381bba99a3@github.com>

On Tue, 15 Jul 2025 19:31:54 GMT, Phil Race <prr at openjdk.org> wrote:

> No issue was raised because no one knew any better. Now we know.

But people would have noted the difference if native app renders it differently in Windows 10..Now both bullet/checkmark and imageicon is superimposed on top of each other..if native app shows it separately I believed people would have complained why JDK was not doing it same..that was my point but anyways..

Also, IIRC the 
checkmark/bullet icon skin is different in Windows 10 where checkmark/bullet icon has blue background (not sure if it still has after the Microsoft theme change in Windows 10 as per this statement

> visual "cue" we've relied on for in Windows 10 was just an accident of some theming that is now gone.

)
as compared to Windows 11 where background is transparent 
so image icon position is now varying w.r.t Windows version 
otherwise imageicon and checkmark/bullet space will be overlapped if same Windows 11 alignment code is used for both 10 and 11.

I believe with theming now gone in Windows 10, the skin should be same without background as it is in Windows11.
So, maybe same code will work for both..Will remove the check..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23324#discussion_r2209197647

From tr at openjdk.org  Wed Jul 16 05:28:41 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 16 Jul 2025 05:28:41 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu
In-Reply-To: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
Message-ID: <QWKqJjQsHS1A5YQjJV6wRdCGZQIYrNRFwBStMbfR1qE=.55fbd2d3-49f9-49d2-bd62-d1d3eb28a513@github.com>

On Tue, 15 Jul 2025 05:40:17 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
> Test stabilization done by requesting focus for the frame before starting the testing. 
> 
> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
> CI link is added in JBS.

test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 120:

> 118:         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> 119:         frame.setVisible(true);
> 120:         frame.toFront();

` frame.toFront();` is required ? Did you try only with `frame.requestFocus();` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2209255971

From syan at openjdk.org  Wed Jul 16 05:51:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 16 Jul 2025 05:51:40 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu
In-Reply-To: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
Message-ID: <23aeDWLJg3BPfaYIt2p7PXvMipZmp4KaIexdeHabEpE=.a2d95535-a3a3-4da6-a6fb-cb6419d22032@github.com>

On Tue, 15 Jul 2025 05:40:17 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
> Test stabilization done by requesting focus for the frame before starting the testing. 
> 
> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
> CI link is added in JBS.

test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 120:

> 118:         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> 119:         frame.setVisible(true);
> 120:         frame.toFront();

Do we need update the copyright year.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2209299268

From abhiscxk at openjdk.org  Wed Jul 16 06:14:46 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 16 Jul 2025 06:14:46 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu
In-Reply-To: <QWKqJjQsHS1A5YQjJV6wRdCGZQIYrNRFwBStMbfR1qE=.55fbd2d3-49f9-49d2-bd62-d1d3eb28a513@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <QWKqJjQsHS1A5YQjJV6wRdCGZQIYrNRFwBStMbfR1qE=.55fbd2d3-49f9-49d2-bd62-d1d3eb28a513@github.com>
Message-ID: <6jFCLigRLz7Ay6XlPo1L9oyuW3kSZxaV-5vf5HmSC_0=.b473f81b-ecea-4173-8b1b-b02fa605dada@github.com>

On Wed, 16 Jul 2025 05:25:39 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
>> Test stabilization done by requesting focus for the frame before starting the testing. 
>> 
>> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
>> CI link is added in JBS.
>
> test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 120:
> 
>> 118:         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>> 119:         frame.setVisible(true);
>> 120:         frame.toFront();
> 
> ` frame.toFront();` is required ? Did you try only with `frame.requestFocus();` ?

`frame.requestFocus()` tries to make the frame current focus owner but it does not guarantee that focus will be granted. So, to be on safer side, it's better to bring the frame to the front.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2209352035

From abhiscxk at openjdk.org  Wed Jul 16 06:25:29 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 16 Jul 2025 06:25:29 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v2]
In-Reply-To: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
Message-ID: <hy1kbEnMDtcq80xSK0d6LAPEF1uP9aVop7KOMXoDuLY=.5ebfd887-8050-48b4-8b60-d26634ec9d16@github.com>

> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
> Test stabilization done by requesting focus for the frame before starting the testing. 
> 
> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
> CI link is added in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  copyright year update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26307/files
  - new: https://git.openjdk.org/jdk/pull/26307/files/d8f6ecc0..53333895

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

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

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

From tr at openjdk.org  Wed Jul 16 06:25:29 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 16 Jul 2025 06:25:29 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v2]
In-Reply-To: <6jFCLigRLz7Ay6XlPo1L9oyuW3kSZxaV-5vf5HmSC_0=.b473f81b-ecea-4173-8b1b-b02fa605dada@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <QWKqJjQsHS1A5YQjJV6wRdCGZQIYrNRFwBStMbfR1qE=.55fbd2d3-49f9-49d2-bd62-d1d3eb28a513@github.com>
 <6jFCLigRLz7Ay6XlPo1L9oyuW3kSZxaV-5vf5HmSC_0=.b473f81b-ecea-4173-8b1b-b02fa605dada@github.com>
Message-ID: <hhLQF7ztq-VWtorNU4sWyMtIGpX79PCtovVQv4KK3Jk=.5f77a3fc-c4fb-4cf4-919f-59f17232ec3a@github.com>

On Wed, 16 Jul 2025 06:12:11 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 120:
>> 
>>> 118:         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>> 119:         frame.setVisible(true);
>>> 120:         frame.toFront();
>> 
>> ` frame.toFront();` is required ? Did you try only with `frame.requestFocus();` ?
>
> `frame.requestFocus()` tries to make the frame current focus owner but it does not guarantee that focus will be granted. So, to be on safer side, it's better to bring the frame to the front and the request keyboard focus.

According to me, `frame.requestFocus()` should work fine for this test. Can u test once without `frame.toFront();` and see if its fine ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2209372265

From abhiscxk at openjdk.org  Wed Jul 16 06:25:29 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 16 Jul 2025 06:25:29 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v2]
In-Reply-To: <23aeDWLJg3BPfaYIt2p7PXvMipZmp4KaIexdeHabEpE=.a2d95535-a3a3-4da6-a6fb-cb6419d22032@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <23aeDWLJg3BPfaYIt2p7PXvMipZmp4KaIexdeHabEpE=.a2d95535-a3a3-4da6-a6fb-cb6419d22032@github.com>
Message-ID: <HuA-5wEIOw5bnOo7ImJpvAL_kqZdEI9A4bB_xiAC4bI=.36beef38-3ec2-44ed-b0d9-c91c71749114@github.com>

On Wed, 16 Jul 2025 05:48:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year update
>
> test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 120:
> 
>> 118:         frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>> 119:         frame.setVisible(true);
>> 120:         frame.toFront();
> 
> Do we need update the copyright year.

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2209374912

From abhiscxk at openjdk.org  Wed Jul 16 06:30:40 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 16 Jul 2025 06:30:40 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v2]
In-Reply-To: <hhLQF7ztq-VWtorNU4sWyMtIGpX79PCtovVQv4KK3Jk=.5f77a3fc-c4fb-4cf4-919f-59f17232ec3a@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <QWKqJjQsHS1A5YQjJV6wRdCGZQIYrNRFwBStMbfR1qE=.55fbd2d3-49f9-49d2-bd62-d1d3eb28a513@github.com>
 <6jFCLigRLz7Ay6XlPo1L9oyuW3kSZxaV-5vf5HmSC_0=.b473f81b-ecea-4173-8b1b-b02fa605dada@github.com>
 <hhLQF7ztq-VWtorNU4sWyMtIGpX79PCtovVQv4KK3Jk=.5f77a3fc-c4fb-4cf4-919f-59f17232ec3a@github.com>
Message-ID: <0D89FMP-9Pr_TcqrBMj2u7ZqLB-j7LvgviKw6Z1QbSs=.7137e33a-8148-4256-9155-84df13edf712@github.com>

On Wed, 16 Jul 2025 06:20:22 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `frame.requestFocus()` tries to make the frame current focus owner but it does not guarantee that focus will be granted. So, to be on safer side, it's better to bring the frame to the front and the request keyboard focus.
>
> According to me, `frame.requestFocus()` should work fine for this test. Can u test once without `frame.toFront();` and see if its fine ?

That may work but since this test was failing intermittently, I would prefer to keep both.
Test even passed without these statements but failing on specific node.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2209382871

From tr at openjdk.org  Wed Jul 16 07:33:42 2025
From: tr at openjdk.org (Tejesh R)
Date: Wed, 16 Jul 2025 07:33:42 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v2]
In-Reply-To: <hy1kbEnMDtcq80xSK0d6LAPEF1uP9aVop7KOMXoDuLY=.5ebfd887-8050-48b4-8b60-d26634ec9d16@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <hy1kbEnMDtcq80xSK0d6LAPEF1uP9aVop7KOMXoDuLY=.5ebfd887-8050-48b4-8b60-d26634ec9d16@github.com>
Message-ID: <tw9CLM9tUa0efiRaarqiDD_rJdkg3YdVFNC5gfiYp3I=.aa50a802-22c3-4866-b70d-a53e5b63a941@github.com>

On Wed, 16 Jul 2025 06:25:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
>> Test stabilization done by requesting focus for the frame before starting the testing. 
>> 
>> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
>> CI link is added in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year update

* @library /javax/swing/regtesthelpers
 * @build Util

Not required.

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

PR Review: https://git.openjdk.org/jdk/pull/26307#pullrequestreview-3023562796

From psadhukhan at openjdk.org  Wed Jul 16 07:46:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 16 Jul 2025 07:46:10 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v35]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <aw_U5iL1vv1Co_qYCWRch07j_AslLB4QLzzwISjm7qo=.743770b3-5052-4ce4-b495-38156fde5585@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge master
 - bullet/checkmark placement for varying imageicon size fix, test update
 - Adjust offset for varying size imageicon
 - squish fix
 - Alignment fix
 - MenuItem with icon fix
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8348760
 - Windows 10 offset correction without icon
 - Fix issue for presence of gap between buller and text only if atleast 1 menuitem has imageicon
 - Text alignment fix
 - ... and 29 more: https://git.openjdk.org/jdk/compare/b85440d0...bc6f064c

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

Changes: https://git.openjdk.org/jdk/pull/23324/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=34
  Stats: 652 lines in 8 files changed: 548 ins; 77 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

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

From abhiscxk at openjdk.org  Wed Jul 16 08:55:52 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 16 Jul 2025 08:55:52 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v2]
In-Reply-To: <tw9CLM9tUa0efiRaarqiDD_rJdkg3YdVFNC5gfiYp3I=.aa50a802-22c3-4866-b70d-a53e5b63a941@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <hy1kbEnMDtcq80xSK0d6LAPEF1uP9aVop7KOMXoDuLY=.5ebfd887-8050-48b4-8b60-d26634ec9d16@github.com>
 <tw9CLM9tUa0efiRaarqiDD_rJdkg3YdVFNC5gfiYp3I=.aa50a802-22c3-4866-b70d-a53e5b63a941@github.com>
Message-ID: <QMq5-fMBqaaCle8fHc5Uf35Bljn1Yjj7DPlQmuqjFAc=.d8c93bbe-228a-4bf2-8a0f-20100e42b260@github.com>

On Wed, 16 Jul 2025 07:31:12 GMT, Tejesh R <tr at openjdk.org> wrote:

> ```
> * @library /javax/swing/regtesthelpers
>  * @build Util
> ```
> 
> Not required.

Util is used to compare two images.

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

PR Comment: https://git.openjdk.org/jdk/pull/26307#issuecomment-3077606075

From aturbanov at openjdk.org  Wed Jul 16 09:57:41 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Jul 2025 09:57:41 GMT
Subject: RFR: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
Message-ID: <d8YthKyinq7l6WqEACitn7o-trIJe_Ps5QZ6P1gBRsM=.dba164c1-0477-462f-9bb4-22ea0e4bafd0@github.com>

On Thu, 24 Apr 2025 09:29:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner.
> `invalidComponents` is an ArrayList.

No changing in behavior here. I assume it's safe to /integrate

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

PR Comment: https://git.openjdk.org/jdk/pull/24845#issuecomment-3077825665

From abhiscxk at openjdk.org  Wed Jul 16 10:34:24 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 16 Jul 2025 10:34:24 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v3]
In-Reply-To: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
Message-ID: <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>

> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
> Test stabilization done by requesting focus for the frame before starting the testing. 
> 
> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
> CI link is added in JBS.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Remove build util

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26307/files
  - new: https://git.openjdk.org/jdk/pull/26307/files/53333895..c7574e11

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

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

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

From abhiscxk at openjdk.org  Wed Jul 16 10:34:25 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 16 Jul 2025 10:34:25 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v2]
In-Reply-To: <QMq5-fMBqaaCle8fHc5Uf35Bljn1Yjj7DPlQmuqjFAc=.d8c93bbe-228a-4bf2-8a0f-20100e42b260@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <hy1kbEnMDtcq80xSK0d6LAPEF1uP9aVop7KOMXoDuLY=.5ebfd887-8050-48b4-8b60-d26634ec9d16@github.com>
 <tw9CLM9tUa0efiRaarqiDD_rJdkg3YdVFNC5gfiYp3I=.aa50a802-22c3-4866-b70d-a53e5b63a941@github.com>
 <QMq5-fMBqaaCle8fHc5Uf35Bljn1Yjj7DPlQmuqjFAc=.d8c93bbe-228a-4bf2-8a0f-20100e42b260@github.com>
Message-ID: <FFt4J5DnRFFOFZPVBDiRERkI5euvdrRT92OCTE1pi-o=.55bb5c0e-3425-47ba-a27a-6ee884bdf924@github.com>

On Wed, 16 Jul 2025 08:53:23 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > ```
> > * @library /javax/swing/regtesthelpers
> >  * @build Util
> > ```

> > Not required.
> 
> Util is used to compare two images.

Removed `build Util` tag, test can be run without it.

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

PR Comment: https://git.openjdk.org/jdk/pull/26307#issuecomment-3077948587

From duke at openjdk.org  Wed Jul 16 12:30:48 2025
From: duke at openjdk.org (Christian Heilmann)
Date: Wed, 16 Jul 2025 12:30:48 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print
In-Reply-To: <bvZKOAWXAUhY3TfbbczlGN3qftulPzgZNmuxovdTSgo=.6c808b39-9ec6-404e-a0b0-ad88755c008d@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <ez2nIrw-TV-NYnzwJCLxnr-PdUYhf_AZm2MiMHiF9hI=.4bc5d42a-0b5a-4e42-a4be-fa66f2b8af2d@github.com>
 <bvZKOAWXAUhY3TfbbczlGN3qftulPzgZNmuxovdTSgo=.6c808b39-9ec6-404e-a0b0-ad88755c008d@github.com>
Message-ID: <DRacRWu8F32wc3I3ms37m9hkiU1WNLIyWi0R87j0Oe0=.e75afd1c-0b40-4f4e-91c8-cab9bf3ef3c4@github.com>

On Tue, 17 Jan 2023 22:17:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> The problem is noticeable when setPageable on java.awt.print.PrinterJob is used. In that case the pageIndex 0 will be used in "PageFormat getPageFormat(int pageIndex)" even though user select page 2 to 2 (or 3, 4, ..).
>> JavaFX printing is based on the given page index, which is in that case wrong.
>
>> The problem is noticeable when setPageable on java.awt.print.PrinterJob is used
> 
> So why is the Test.java in the bugreport not using it ? And yet claiming it shows the problem >
> And can we have a test with this fix, even if it is manual, so I can run it BEFORE and AFTER the  fix to verify it.
> 
> Perhaps you can identify an existing failing test that you can reference ?

@prrace 

Issue only occurs on macOS.
 
To reproduce the issue on macOS. Start PageRanges.class from test/jdk/java/awt/print/PrinterJob/PageRanges.java and choose print page range 2-3.
The App also works as a standalone.
 
What happens:
On macOS only page 3 is printed.
 
What should happen:
On macOS page 2 and page 3 is printed.

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

PR Comment: https://git.openjdk.org/jdk/pull/11266#issuecomment-3078355586

From mbaesken at openjdk.org  Wed Jul 16 12:50:31 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Jul 2025 12:50:31 GMT
Subject: RFR: 8362390: AIX make fails in awt_GraphicsEnv.c
Message-ID: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>

We have build errors on AIX , seems related to [JDK-8354415](https://bugs.openjdk.org/browse/JDK-8354415) :


=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_libawt_xawt_awt_GraphicsEnv.o:
/priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1751:43: error: unknown type name 'XRRModeInfo'
1751 | static jint refreshRateFromModeInfo(const XRRModeInfo *modeInfo) {
      | ^
/priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1758:31: error: use of undeclared identifier 'RR_Interlace'
1758 | if (modeInfo->modeFlags & RR_Interlace) {
      | ^
/priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1762:31: error: use of undeclared identifier 'RR_DoubleScan'
1762 | if (modeInfo->modeFlags & RR_DoubleScan) {
      | ^
/priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1769:43: error: unknown type name 'XRRCrtcInfo'
1769 | static inline Bool isLandscapeOrientation(XRRCrtcInfo* info) {
      | ^
/priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1773:30: error: use of undeclared identifier 'RR_Rotate_0'
1773 | return info->rotation == RR_Rotate_0 || info->rotation == RR_Rotate_180;
      | ^
   ... (rest of output omitted)


Seems we miss some checks for the NO_XRANDR macro.

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

Commit messages:
 - JDK-8362390

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

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

From prr at openjdk.org  Wed Jul 16 16:34:41 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 16:34:41 GMT
Subject: RFR: 8362390: AIX make fails in awt_GraphicsEnv.c
In-Reply-To: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
References: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
Message-ID: <ghWADbs0qH2p1fiXqgxCwXZ_lNRS1WYANMo_oPXJ3aQ=.ff01808e-3d83-40db-a92f-e19f74da2de1@github.com>

On Wed, 16 Jul 2025 12:44:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have build errors on AIX , seems related to [JDK-8354415](https://bugs.openjdk.org/browse/JDK-8354415) :
> 
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libawt_xawt_awt_GraphicsEnv.o:
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1751:43: error: unknown type name 'XRRModeInfo'
> 1751 | static jint refreshRateFromModeInfo(const XRRModeInfo *modeInfo) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1758:31: error: use of undeclared identifier 'RR_Interlace'
> 1758 | if (modeInfo->modeFlags & RR_Interlace) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1762:31: error: use of undeclared identifier 'RR_DoubleScan'
> 1762 | if (modeInfo->modeFlags & RR_DoubleScan) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1769:43: error: unknown type name 'XRRCrtcInfo'
> 1769 | static inline Bool isLandscapeOrientation(XRRCrtcInfo* info) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1773:30: error: use of undeclared identifier 'RR_Rotate_0'
> 1773 | return info->rotation == RR_Rotate_0 || info->rotation == RR_Rotate_180;
>       | ^
>    ... (rest of output omitted)
> 
> 
> Seems we miss some checks for the NO_XRANDR macro.

SFAICS NO_XRANDR is set only for the AIX build, so I have no issues with this.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26348#pullrequestreview-3025830624

From serb at openjdk.org  Wed Jul 16 17:59:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Jul 2025 17:59:48 GMT
Subject: RFR: 8362390: AIX make fails in awt_GraphicsEnv.c
In-Reply-To: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
References: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
Message-ID: <O5R0_eTuB_Ou2HkLcSpRl-X_RDvzElj0oG9BV1GJot4=.57cfa864-f99b-45f6-9cc1-a686c95fae40@github.com>

On Wed, 16 Jul 2025 12:44:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have build errors on AIX , seems related to [JDK-8354415](https://bugs.openjdk.org/browse/JDK-8354415) :
> 
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libawt_xawt_awt_GraphicsEnv.o:
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1751:43: error: unknown type name 'XRRModeInfo'
> 1751 | static jint refreshRateFromModeInfo(const XRRModeInfo *modeInfo) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1758:31: error: use of undeclared identifier 'RR_Interlace'
> 1758 | if (modeInfo->modeFlags & RR_Interlace) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1762:31: error: use of undeclared identifier 'RR_DoubleScan'
> 1762 | if (modeInfo->modeFlags & RR_DoubleScan) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1769:43: error: unknown type name 'XRRCrtcInfo'
> 1769 | static inline Bool isLandscapeOrientation(XRRCrtcInfo* info) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1773:30: error: use of undeclared identifier 'RR_Rotate_0'
> 1773 | return info->rotation == RR_Rotate_0 || info->rotation == RR_Rotate_180;
>       | ^
>    ... (rest of output omitted)
> 
> 
> Seems we miss some checks for the NO_XRANDR macro.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26348#pullrequestreview-3026188465

From serb at openjdk.org  Wed Jul 16 18:00:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Jul 2025 18:00:49 GMT
Subject: RFR: 8354415: [Ubuntu25.04]
 api/java_awt/GraphicsDevice/indexTGF.html#SetDisplayMode -
 setDisplayMode_REFRESH_RATE_UNKNOWN fails: Height is different on vnc
In-Reply-To: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
References: <E9I6XCLk5J1G1M1TsSh-1xp6ylExP1m-NIuMkouVZrY=.026139ed-1d47-4bab-bb68-97de6d41e4c8@github.com>
Message-ID: <p6hn6IJC7qKmvTmTEU9EaZ12HurPREKaSkcya0snbK4=.e075bba2-7095-4107-b03f-bb0cc5b2bc5f@github.com>

On Fri, 11 Jul 2025 15:47:33 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> On Linux, we are currently use XRRSetScreenConfigAndRate to change the display mode. This works in most cases, except for some VNC-configured hosts, where the display change may not occur.
> One of the conformance tests fails on these hosts.
> 
> It was discovered, that the xrandr utility app works fine on these hosts and uses the Crtc and Output Randr APIs, which provide more fine-grained control over display settings.
> 
> This changeset utilizes the Crtc and Output Randr APIs to change the display mode.
> 
> Currently, changing the display mode is only [available when running a single screen](https://github.com/openjdk/jdk/blob/a86dd56de34f730b42593236f17118ef5ce4985a/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L365).
> This limitation remains, but we may remove it in the future. A separate issue [has been filed](https://bugs.openjdk.org/browse/JDK-8361968) for this purpose.
> 
> The `awt.x11useOldConfigDisplayMode` system property enables the old behavior. Perhaps there's a better name for it.
> 
> Testing looks good on VNC and local machines.

Additionally to the comments above I think some test should be updated to touch both cases when the new property is set and not.

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

PR Comment: https://git.openjdk.org/jdk/pull/26268#issuecomment-3079685847

From dnguyen at openjdk.org  Wed Jul 16 19:19:44 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 16 Jul 2025 19:19:44 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v3]
In-Reply-To: <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>
Message-ID: <viqhmZ8hRtW3iZNkgVfgj8S0iFS5_eIVIn9mlcAyxbE=.12d47cbc-e80e-4039-ae8a-cf9a23f80f2a@github.com>

On Wed, 16 Jul 2025 10:34:24 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
>> Test stabilization done by requesting focus for the frame before starting the testing. 
>> 
>> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
>> CI link is added in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove build util

Updated changes look good after review comments. Tested this myself and the stabilization does seem to be good. Hopefully it stays that way long term.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26307#pullrequestreview-3026482592

From prr at openjdk.org  Wed Jul 16 20:57:40 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 20:57:40 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v2]
In-Reply-To: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
Message-ID: <LnttL1KQz2s9r25Gfho6AANrQ8I35ji8309xklPmicE=.46da65ce-97b9-4169-a9e8-9e6ee932a309@github.com>

> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
> 
> I don't see a way to add a test to verify this clean up.

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

  8362291

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26332/files
  - new: https://git.openjdk.org/jdk/pull/26332/files/bc18d382..ee8f77a5

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

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

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

From prr at openjdk.org  Wed Jul 16 20:57:42 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 20:57:42 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v2]
In-Reply-To: <YkRM74J21Mt7KGVB-s-oL1MZqrRv1PmUPZmwH31oYQY=.521bd7ee-aa6d-44b2-b7be-7532adb5d6e4@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <MVY6_1ZmemQFZtt-qmwrQu9qIljfICRHkXi3sthDfcg=.0ada8873-6f95-443c-911f-789e1e91dca0@github.com>
 <y7_BhMRnV26x8_Y3JFF6JteS-ymYJm352a1zIetuHoQ=.231e78eb-f6b1-4c45-a5df-73352f2a3dd2@github.com>
 <YkRM74J21Mt7KGVB-s-oL1MZqrRv1PmUPZmwH31oYQY=.521bd7ee-aa6d-44b2-b7be-7532adb5d6e4@github.com>
Message-ID: <M-UGNMtPMrFH2FwmQGwqFgBIbiicPwj1EK2rM8CJ9sE=.c36d59e6-e485-4680-bd9c-3258f77facc0@github.com>

On Wed, 16 Jul 2025 00:09:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It doesn't have to be. Is it a problem that it is ?
>
> Yeah, if it does not need to be, we can skip it; otherwise, we can update all existing implementations to follow the same pattern.

I removed it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2211587120

From prr at openjdk.org  Wed Jul 16 20:57:44 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 20:57:44 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v2]
In-Reply-To: <y7_BhMRnV26x8_Y3JFF6JteS-ymYJm352a1zIetuHoQ=.231e78eb-f6b1-4c45-a5df-73352f2a3dd2@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <MVY6_1ZmemQFZtt-qmwrQu9qIljfICRHkXi3sthDfcg=.0ada8873-6f95-443c-911f-789e1e91dca0@github.com>
 <y7_BhMRnV26x8_Y3JFF6JteS-ymYJm352a1zIetuHoQ=.231e78eb-f6b1-4c45-a5df-73352f2a3dd2@github.com>
Message-ID: <1OiJp9kWd0TKfgdvjLtoBs0AH6oAg4kPtAkWbbv1Chw=.4ada9dae-c415-434a-839b-095f6e8960f0@github.com>

On Tue, 15 Jul 2025 22:40:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 154:
>> 
>>> 152: 
>>> 153:         public synchronized void dispose() {
>>> 154:             if (displayReconfigContext != 0L) {
>> 
>> can it be 0 here? it seems we never register 0 pointer, and we have a guard in native to be safe.
>
> and is there any harm in the check ?

I removed the check

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2211585561

From prr at openjdk.org  Wed Jul 16 21:00:43 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 21:00:43 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v2]
In-Reply-To: <kjWS4HjWniyPaP-NFaOPy0AiuWbOKb2_WliKRh-KY3U=.916e2bd3-7086-4299-aa9f-48342db385ee@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <G7ZYGfikLqwjkUUnoTW0nbamkrBrPjhVn4R07JWRMKY=.06dc0dfe-01ca-4279-9e60-fc2bdb1d48dd@github.com>
 <kjWS4HjWniyPaP-NFaOPy0AiuWbOKb2_WliKRh-KY3U=.916e2bd3-7086-4299-aa9f-48342db385ee@github.com>
Message-ID: <rTMcB0dPK2diMFgJyVerzr0vfH7Hh0aG8ESnVp3Ywas=.cf3e44a0-2a3e-4f73-9c4c-a16ab14f7972@github.com>

On Wed, 16 Jul 2025 00:11:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I am not *expecting* it to be called twice. I'm just saying that with this check it would be safe if it were.
>> Not sure I even need synchronization here. Only the Disposer will have a reference.
>> So I could remove synchronized, remove the != 0 check  ... but I don't see a problem either way.
>
> That would be great if we could drop all unneeded code.

I removed the != 0 and the synchronized modifier

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2211591459

From prr at openjdk.org  Wed Jul 16 21:00:42 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 21:00:42 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v2]
In-Reply-To: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
Message-ID: <zcabg8J_HDgCvxEFqTqMNSZaTkrIRjQbuL3v7mCwFXM=.2e0d8bbf-c827-4963-8361-a6bc916ab968@github.com>

> Eliminate a finalize() method in the Swing macOS implementation.
> 
> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
> 
> import javax.swing.JTabbedPane;
> import javax.swing.plaf.TabbedPaneUI;
> 
> public class CreateTabbedPaneUIStressTest {
> 
>    public static void main(String[] args) {
>        for (int i=0; i<1000000000; i++) {
>            JTabbedPane jtp = new JTabbedPane();
>            TabbedPaneUI tpui = jtp.getUI();
>        }
>    }
> }
> 
> 
> I also monitored the process size using 'top'.
> And when I commented out the native call that did the free and re-tested I saw process size grow.
> 
> Turning the above into a useful regression test doesn't seem possible to me.
> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.

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

  8362289

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26331/files
  - new: https://git.openjdk.org/jdk/pull/26331/files/130fdc5e..2c561738

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

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

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

From prr at openjdk.org  Wed Jul 16 21:03:25 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 21:03:25 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v2]
In-Reply-To: <wh5FY46Jdi_keoyVDm6lg4SKBi165YSM_Yk4_Ybe5fU=.2b827f8d-cf16-4163-9588-64fdacbc3706@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <KOPJ6k4qDUFYdIBJrExPysmQYPyZHtO81yLlvwjyaUo=.95b5527e-403e-4274-8aa6-3b4b95062c63@github.com>
 <W5AhemC_BCQ6emEIzYH-evy1gzqHdT0cu6nQtkLVc-4=.148b59e9-2032-4282-9955-8e45a56f5f9f@github.com>
 <wh5FY46Jdi_keoyVDm6lg4SKBi165YSM_Yk4_Ybe5fU=.2b827f8d-cf16-4163-9588-64fdacbc3706@github.com>
Message-ID: <yDdR01gzJQNDTcG4f3ADm6KMlt4EFzVgCeBqZ3S_jmE=.2fe0e349-a0fa-498d-9132-3cb5b17f77fd@github.com>

On Wed, 16 Jul 2025 02:00:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I think that would be OK, meaning probably harmless. But I don't know if this case actually requires it.
>> Where I've seen a problem like this a Java object is used at an earlier point in the method and not again and so becomes eligible to be freed, but some native resource it held is needed later but is already freed along with its no longer references holder.
>> 
>> Here, if this object (the JRSUIControl) becomes unreachable during construction, and so the referent and disposer are also unreachable outside this object, they are still going to be live until we reach code in the constructor which uses them and since  the referent and the disposer are passed into addRecord they'll be live there until stored.
>> 
>> But these cases are subtle, maybe I'm missing something. Can you expand on the scenario ?
>> Or maybe there's some other patterns where we use Disposer that it is needed ?
>
> I think I understand why reachabilityFence is used [here](https://github.com/openjdk/jdk/blob/a5c9bc70324693e9d0b25bb2c51b91dfc750c453/src/java.base/share/classes/jdk/internal/ref/PhantomCleanable.java#L84). That code first registers the object in the cleanup queue and then continues executing the rest of the constructor. As far as I understand, the object could be collected between the registration and the end of the constructor so the cleaner will be called on a partially constructed object.
> 
> If that assumption is correct then in the change above the code:
>         nativeMap = new HashMap<Key, DoubleValue>();
>         changes = new HashMap<Key, DoubleValue>();
> might never be executed and the native disposer will be called before, not an issue in this particular case but good to know.
> Or I missing something.

I think that's right. At first I thought you were referring to the constructor of the thing that wants to use the cleaner, but you mean the constructor of the Cleanable itself may be still under construction when the referent is collected and installing the reachabilityFence at the end of the constructor prevents that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2211601222

From aturbanov at openjdk.org  Wed Jul 16 21:08:05 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Jul 2025 21:08:05 GMT
Subject: Integrated: 8357226: Remove unnecessary List.indexOf from
 RepaintManager.removeInvalidComponent
In-Reply-To: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
References: <_pLf9918EhjvAMh1-FIb3HkaneujwjTe4iCEGPMBK8Y=.080f1cea-4fd5-4b94-9523-87bd20d11bbc@github.com>
Message-ID: <_r9reyeK5BWAlKKupmESVmaZv1d8c3vMZFp7KuDcKY8=.c9d6a3d9-714b-4efd-8a76-a7319926af08@github.com>

On Thu, 24 Apr 2025 09:29:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to call `List.indexOf(Object)` before `List.remove(int)`. Instead we can call `List.remove(Object)` directly. It's faster and cleaner.
> `invalidComponents` is an ArrayList.

This pull request has now been integrated.

Changeset: 20b5f097
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20b5f097773043068ce732e0fa30c2726273e40a
Stats:     6 lines in 1 file changed: 0 ins; 3 del; 3 mod

8357226: Remove unnecessary List.indexOf from RepaintManager.removeInvalidComponent

Reviewed-by: azvegint, serb

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

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

From prr at openjdk.org  Wed Jul 16 21:39:13 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 21:39:13 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v3]
In-Reply-To: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
Message-ID: <JSPDWqbFDoxlcQIWdkA9-Pzhl-b6N3W8-m-bp_Ed_Pw=.b8bd0157-3832-4721-acf1-3513d4393e98@github.com>

> Eliminate a finalize() method in the Swing macOS implementation.
> 
> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
> 
> import javax.swing.JTabbedPane;
> import javax.swing.plaf.TabbedPaneUI;
> 
> public class CreateTabbedPaneUIStressTest {
> 
>    public static void main(String[] args) {
>        for (int i=0; i<1000000000; i++) {
>            JTabbedPane jtp = new JTabbedPane();
>            TabbedPaneUI tpui = jtp.getUI();
>        }
>    }
> }
> 
> 
> I also monitored the process size using 'top'.
> And when I commented out the native call that did the free and re-tested I saw process size grow.
> 
> Turning the above into a useful regression test doesn't seem possible to me.
> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.

Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into jrsuicontrols
 - 8362289
 - 8362289
 - 8362289

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

Changes: https://git.openjdk.org/jdk/pull/26331/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26331&range=02
  Stats: 19 lines in 1 file changed: 13 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/26331.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26331/head:pull/26331

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

From serb at openjdk.org  Wed Jul 16 22:07:00 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Jul 2025 22:07:00 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v2]
In-Reply-To: <LnttL1KQz2s9r25Gfho6AANrQ8I35ji8309xklPmicE=.46da65ce-97b9-4169-a9e8-9e6ee932a309@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <LnttL1KQz2s9r25Gfho6AANrQ8I35ji8309xklPmicE=.46da65ce-97b9-4169-a9e8-9e6ee932a309@github.com>
Message-ID: <1fDImbJQBqQMU65dNlqEQv4VdT3OsyU151CYJgxK_hI=.cc2d2a42-7259-4c0e-bcc7-21c8b3a49d49@github.com>

On Wed, 16 Jul 2025 20:57:40 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
>> 
>> I don't see a way to add a test to verify this clean up.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362291

src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 157:

> 155:                 deregisterDisplayReconfiguration(displayReconfigContext);
> 156:             } catch (Throwable t) {
> 157:                 // Runs on disposer thread, can't allow an exception to escape.

What do you think about moving this "catch Throwable" into Disposer itself? As of now since https://github.com/openjdk/jdk/pull/9890 we ignore "Exception" only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2211699632

From serb at openjdk.org  Wed Jul 16 22:09:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Jul 2025 22:09:50 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v3]
In-Reply-To: <JSPDWqbFDoxlcQIWdkA9-Pzhl-b6N3W8-m-bp_Ed_Pw=.b8bd0157-3832-4721-acf1-3513d4393e98@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <JSPDWqbFDoxlcQIWdkA9-Pzhl-b6N3W8-m-bp_Ed_Pw=.b8bd0157-3832-4721-acf1-3513d4393e98@github.com>
Message-ID: <jQkz2HZMZOa9EBqKNXvTdWAZQ5XXnCzemK3CkT9umcc=.0d908f90-6c6c-463d-acf2-d91b339fe12b@github.com>

On Wed, 16 Jul 2025 21:39:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Eliminate a finalize() method in the Swing macOS implementation.
>> 
>> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
>> 
>> import javax.swing.JTabbedPane;
>> import javax.swing.plaf.TabbedPaneUI;
>> 
>> public class CreateTabbedPaneUIStressTest {
>> 
>>    public static void main(String[] args) {
>>        for (int i=0; i<1000000000; i++) {
>>            JTabbedPane jtp = new JTabbedPane();
>>            TabbedPaneUI tpui = jtp.getUI();
>>        }
>>    }
>> }
>> 
>> 
>> I also monitored the process size using 'top'.
>> And when I commented out the native call that did the free and re-tested I saw process size grow.
>> 
>> Turning the above into a useful regression test doesn't seem possible to me.
>> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.
>
> Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into jrsuicontrols
>  - 8362289
>  - 8362289
>  - 8362289

src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 134:

> 132:             } catch (Throwable t) {
> 133:             }
> 134:             cfDictionaryPtr = 0;

cfDictionaryPtr = 0 seems is not needed as well we do not reset pointers in other classes -> then we can mark cfDictionaryPtr as final.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2211703208

From prr at openjdk.org  Wed Jul 16 22:21:17 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 22:21:17 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize()
Message-ID: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>

Replace finalization with 2D Disposer

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

Commit messages:
 - 8362452

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

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

From prr at openjdk.org  Wed Jul 16 22:34:02 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 22:34:02 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v2]
In-Reply-To: <1fDImbJQBqQMU65dNlqEQv4VdT3OsyU151CYJgxK_hI=.cc2d2a42-7259-4c0e-bcc7-21c8b3a49d49@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <LnttL1KQz2s9r25Gfho6AANrQ8I35ji8309xklPmicE=.46da65ce-97b9-4169-a9e8-9e6ee932a309@github.com>
 <1fDImbJQBqQMU65dNlqEQv4VdT3OsyU151CYJgxK_hI=.cc2d2a42-7259-4c0e-bcc7-21c8b3a49d49@github.com>
Message-ID: <B4Cq7kMn7Wy0telbXgAjze6YmsdHy_a47AvRfFWV4xA=.b87a4536-9d9b-4852-a4fd-c80bd7c8fd1c@github.com>

On Wed, 16 Jul 2025 22:04:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8362291
>
> src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 157:
> 
>> 155:                 deregisterDisplayReconfiguration(displayReconfigContext);
>> 156:             } catch (Throwable t) {
>> 157:                 // Runs on disposer thread, can't allow an exception to escape.
> 
> What do you think about moving this "catch Throwable" into Disposer itself? As of now since https://github.com/openjdk/jdk/pull/9890 we ignore "Exception" only.

I can do that. I can't think of a problem with it.
I should probably then do the same for the other catches of Exception in that file.

I'm a bit on the fence about whether I should
1. keep the print statements there
2. remove them
3. hide them behind a debugging option

I think I'll leave them alone and if we need to we can adjust in another PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2211734473

From prr at openjdk.org  Wed Jul 16 22:34:02 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 22:34:02 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v3]
In-Reply-To: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
Message-ID: <vLJ6o61DqAU_j1T7143pMYpVcAHyEKaj_ISpxUEZYgw=.f1f8c75e-2187-40b5-a360-3c6bc776eca3@github.com>

> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
> 
> I don't see a way to add a test to verify this clean up.

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

  8362291

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26332/files
  - new: https://git.openjdk.org/jdk/pull/26332/files/ee8f77a5..5e9d55ff

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

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

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

From prr at openjdk.org  Wed Jul 16 22:45:22 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 22:45:22 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v3]
In-Reply-To: <jQkz2HZMZOa9EBqKNXvTdWAZQ5XXnCzemK3CkT9umcc=.0d908f90-6c6c-463d-acf2-d91b339fe12b@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <JSPDWqbFDoxlcQIWdkA9-Pzhl-b6N3W8-m-bp_Ed_Pw=.b8bd0157-3832-4721-acf1-3513d4393e98@github.com>
 <jQkz2HZMZOa9EBqKNXvTdWAZQ5XXnCzemK3CkT9umcc=.0d908f90-6c6c-463d-acf2-d91b339fe12b@github.com>
Message-ID: <pjL0q8CaxqRkz_mxMGGMS6MyAVrp-GcyRC2x5bsxERI=.9a1ba995-801b-4559-a719-ab04381eb9a9@github.com>

On Wed, 16 Jul 2025 22:07:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into jrsuicontrols
>>  - 8362289
>>  - 8362289
>>  - 8362289
>
> src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java line 134:
> 
>> 132:             } catch (Throwable t) {
>> 133:             }
>> 134:             cfDictionaryPtr = 0;
> 
> cfDictionaryPtr = 0 seems is not needed as well we do not reset pointers in other classes -> then we can mark cfDictionaryPtr as final.

it can already be made final in the main class but I can do it as well in the DisposerRecord

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2211745825

From prr at openjdk.org  Wed Jul 16 22:45:21 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 16 Jul 2025 22:45:21 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
Message-ID: <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>

> Eliminate a finalize() method in the Swing macOS implementation.
> 
> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
> 
> import javax.swing.JTabbedPane;
> import javax.swing.plaf.TabbedPaneUI;
> 
> public class CreateTabbedPaneUIStressTest {
> 
>    public static void main(String[] args) {
>        for (int i=0; i<1000000000; i++) {
>            JTabbedPane jtp = new JTabbedPane();
>            TabbedPaneUI tpui = jtp.getUI();
>        }
>    }
> }
> 
> 
> I also monitored the process size using 'top'.
> And when I commented out the native call that did the free and re-tested I saw process size grow.
> 
> Turning the above into a useful regression test doesn't seem possible to me.
> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.

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

  JRSUIControl.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26331/files
  - new: https://git.openjdk.org/jdk/pull/26331/files/21ad3a11..3b4556cf

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

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

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

From achung at openjdk.org  Wed Jul 16 23:15:37 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 16 Jul 2025 23:15:37 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v25]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <U69ZO4AurDU0gnQ1BmBOWwhaGRtC1iVoGrtvnl_Hx2Y=.b5b54f18-4c0e-4bea-970c-f337ce8bfb3c@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  update robot specification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/41934c61..0496e20e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=23-24

  Stats: 75 lines in 1 file changed: 19 ins; 13 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/22044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044

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

From bchristi at openjdk.org  Thu Jul 17 00:35:48 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 17 Jul 2025 00:35:48 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v3]
In-Reply-To: <vLJ6o61DqAU_j1T7143pMYpVcAHyEKaj_ISpxUEZYgw=.f1f8c75e-2187-40b5-a360-3c6bc776eca3@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <vLJ6o61DqAU_j1T7143pMYpVcAHyEKaj_ISpxUEZYgw=.f1f8c75e-2187-40b5-a360-3c6bc776eca3@github.com>
Message-ID: <Q-6SMlvHJ4FyExRyPzPfj_8iIpmdVDVYYwW0RLqHB9s=.7f414c33-e08a-4446-a4c4-01eb79190522@github.com>

On Wed, 16 Jul 2025 22:34:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
>> 
>> I don't see a way to add a test to verify this clean up.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362291

Changes requested by bchristi (Reviewer).

src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 98:

> 96:     /** Reference to the display reconfiguration callback context. */
> 97:     private final long displayReconfigContext;
> 98:     private Object disposerReferent = new Object();

`disposerReferent` can be final

src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 147:

> 145: 
> 146:     private static class CGEDisposerRecord implements DisposerRecord {
> 147:         private long displayReconfigContext;

`displayReconfigContext` should be final

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

PR Review: https://git.openjdk.org/jdk/pull/26332#pullrequestreview-3027331854
PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2211890827
PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2211889216

From psadhukhan at openjdk.org  Thu Jul 17 02:18:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 17 Jul 2025 02:18:16 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v36]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <FVhRfLRjStIosXDDhAVCkQxYLnnel4fpqAFly3UhnrA=.fd1ec703-4ae4-4312-b38b-028afe57d2b1@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove Windows version check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/bc6f064c..c5f5ce29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=34-35

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

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

From serb at openjdk.org  Thu Jul 17 02:49:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 17 Jul 2025 02:49:48 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <rTMcB0dPK2diMFgJyVerzr0vfH7Hh0aG8ESnVp3Ywas=.cf3e44a0-2a3e-4f73-9c4c-a16ab14f7972@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <G7ZYGfikLqwjkUUnoTW0nbamkrBrPjhVn4R07JWRMKY=.06dc0dfe-01ca-4279-9e60-fc2bdb1d48dd@github.com>
 <kjWS4HjWniyPaP-NFaOPy0AiuWbOKb2_WliKRh-KY3U=.916e2bd3-7086-4299-aa9f-48342db385ee@github.com>
 <rTMcB0dPK2diMFgJyVerzr0vfH7Hh0aG8ESnVp3Ywas=.cf3e44a0-2a3e-4f73-9c4c-a16ab14f7972@github.com>
Message-ID: <bg0IYRbTeADsy6Khz45JALrGYZ_iNdvTqIinObT7y5I=.8bffc1af-b649-4406-a203-983ba763041c@github.com>

On Wed, 16 Jul 2025 20:55:00 GMT, Phil Race <prr at openjdk.org> wrote:

>> That would be great if we could drop all unneeded code.
>
> I removed the != 0 and the synchronized modifier

Looks fine, the catch (Throwable t) seems will be unnecessary after another PR will be integrated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2212036539

From serb at openjdk.org  Thu Jul 17 04:31:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 17 Jul 2025 04:31:48 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize()
In-Reply-To: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
Message-ID: <1E8wOofchCVLJLhg3UJYG9zV5CZHrgYmCkjQJsHEq_0=.aa6ada46-9334-4c05-abdf-5828d6fd8680@github.com>

On Wed, 16 Jul 2025 20:47:23 GMT, Phil Race <prr at openjdk.org> wrote:

> Replace finalization with 2D Disposer

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 651:

> 649: 
> 650:         public void dispose() {
> 651:             synchronized (lock) {

I do not think this synchronization is necessary. Before the patch it was used to guard access to fNSPrintInfo field, which might have been lazily initialized and disposed concurrently.

Now we use the Disposer only if fNSPrintInfo has been used and initialized -> we saved it to NSPrintInfoDisposer and from that point it is never changed.

So we can drop the lock, and all check for the field(seems createNSPrintInfo cannot return -1) + mark it as final

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26359#discussion_r2212226803

From abhiscxk at openjdk.org  Thu Jul 17 04:33:53 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 17 Jul 2025 04:33:53 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v4]
In-Reply-To: <PxraFDnGTaBbv8TKEkJYLR97I95Whzhmf8oWXb9f4bc=.fde406a7-7736-4fa7-a820-d3ff80b96c44@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <PxraFDnGTaBbv8TKEkJYLR97I95Whzhmf8oWXb9f4bc=.fde406a7-7736-4fa7-a820-d3ff80b96c44@github.com>
Message-ID: <eaUvF8i8qwcAGRWQ33JpvMCpfXjvlIm1FDkPp2XxHbU=.d7c9de16-6b38-4f43-a9af-3e615b7b2dfb@github.com>

On Mon, 14 Jul 2025 08:36:57 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> **Issue** : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
>> 
>> **Analysis** : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
>> 
>> **Proposed Fix** : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.
>> 
>> **Testing** : Manual test case has been added to verify the fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Role description code moved to TabButtonAccessibility

@azuev-java Please review

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

PR Comment: https://git.openjdk.org/jdk/pull/26096#issuecomment-3082455132

From dnguyen at openjdk.org  Thu Jul 17 04:53:46 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 17 Jul 2025 04:53:46 GMT
Subject: RFR: 8361190: Test
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java fails on MacOS X
In-Reply-To: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
References: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
Message-ID: <XukiG6VfBwfeXyfI_VvpblBkh47jW0fqyaxTmLnI7io=.138c6acf-07f4-4d6c-a84e-01a115a7d08a@github.com>

On Tue, 8 Jul 2025 16:34:31 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Add more timeout for the test to pass.

> I thought it will explain better the relation between different tests and fixes. I understand that this will increase the chain of dependencies between PRs. Please let me know if it is better to group these PRs in one.

I think since this fix is pretty straight-forward but dependent on https://github.com/openjdk/jdk/pull/26162, I'm leaning towards combining the PRs and adding a note to the other PR. I see multiple PRs possibly related though, so I'm not positive if this can apply to your other PRs.

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

PR Review: https://git.openjdk.org/jdk/pull/26196#pullrequestreview-3027851999

From serb at openjdk.org  Thu Jul 17 05:44:51 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 17 Jul 2025 05:44:51 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <yDdR01gzJQNDTcG4f3ADm6KMlt4EFzVgCeBqZ3S_jmE=.2fe0e349-a0fa-498d-9132-3cb5b17f77fd@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <KOPJ6k4qDUFYdIBJrExPysmQYPyZHtO81yLlvwjyaUo=.95b5527e-403e-4274-8aa6-3b4b95062c63@github.com>
 <W5AhemC_BCQ6emEIzYH-evy1gzqHdT0cu6nQtkLVc-4=.148b59e9-2032-4282-9955-8e45a56f5f9f@github.com>
 <wh5FY46Jdi_keoyVDm6lg4SKBi165YSM_Yk4_Ybe5fU=.2b827f8d-cf16-4163-9588-64fdacbc3706@github.com>
 <yDdR01gzJQNDTcG4f3ADm6KMlt4EFzVgCeBqZ3S_jmE=.2fe0e349-a0fa-498d-9132-3cb5b17f77fd@github.com>
Message-ID: <FPCAlqcKQK2wnojZDh4deK68fxmiUtWhvUXzys2Foaw=.a7f563e4-7e29-46ec-97da-6307097f58fc@github.com>

On Wed, 16 Jul 2025 21:00:03 GMT, Phil Race <prr at openjdk.org> wrote:

>> I think I understand why reachabilityFence is used [here](https://github.com/openjdk/jdk/blob/a5c9bc70324693e9d0b25bb2c51b91dfc750c453/src/java.base/share/classes/jdk/internal/ref/PhantomCleanable.java#L84). That code first registers the object in the cleanup queue and then continues executing the rest of the constructor. As far as I understand, the object could be collected between the registration and the end of the constructor so the cleaner will be called on a partially constructed object.
>> 
>> If that assumption is correct then in the change above the code:
>>         nativeMap = new HashMap<Key, DoubleValue>();
>>         changes = new HashMap<Key, DoubleValue>();
>> might never be executed and the native disposer will be called before, not an issue in this particular case but good to know.
>> Or I missing something.
>
> I think that's right. At first I thought you were referring to the constructor of the thing that wants to use the cleaner, but you mean the constructor of the Cleanable itself may be still under construction when the referent is collected and installing the reachabilityFence at the end of the constructor prevents that.

I tried to compare how Cleaner and Disposer are used. I found that in most cases Cleaner uses `this` as the object to track. But Disposer often uses a separate object like disposerReferent or some kind of anchor. This patch is one example. In some places we even replaced this with a different object. You can see that in the following RFR:
https://bugs.openjdk.org/browse/JDK-8030099
https://mail.openjdk.org/pipermail/swing-dev/2015-October/005053.html

I think I found the reason: https://bugs.openjdk.org/browse/JDK-8071507

In older versions of the JDK the Disposer had to use phantom references. Phantom references allow native cleanup to happen after the object is 100% no longer reachable. But this had a problem, the object stayed in memory until the reference was added to the queue and the code called [clear](https://github.com/openjdk/jdk/blob/bc72f476d1281dae2adb2322004c9880c1a6b66c/src/java.desktop/share/classes/sun/java2d/Disposer.java#L134).

To avoid keeping large AWT or Java2D objects in memory for too long the code used small helper objects as referents instead of using the real object.

Now the problem described in JDK-8071507 is fixed. So maybe we no longer need to use small disposer referents. And you can check that by the test from the description of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2212323719

From clanger at openjdk.org  Thu Jul 17 06:52:47 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 17 Jul 2025 06:52:47 GMT
Subject: RFR: 8362390: AIX make fails in awt_GraphicsEnv.c
In-Reply-To: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
References: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
Message-ID: <7C_jxReTh7AUTL2SXMZAQP02Jz4DbZWYsLlSZwT2BmQ=.38675d7a-8729-40e2-b611-54ea8dadea7a@github.com>

On Wed, 16 Jul 2025 12:44:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have build errors on AIX , seems related to [JDK-8354415](https://bugs.openjdk.org/browse/JDK-8354415) :
> 
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libawt_xawt_awt_GraphicsEnv.o:
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1751:43: error: unknown type name 'XRRModeInfo'
> 1751 | static jint refreshRateFromModeInfo(const XRRModeInfo *modeInfo) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1758:31: error: use of undeclared identifier 'RR_Interlace'
> 1758 | if (modeInfo->modeFlags & RR_Interlace) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1762:31: error: use of undeclared identifier 'RR_DoubleScan'
> 1762 | if (modeInfo->modeFlags & RR_DoubleScan) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1769:43: error: unknown type name 'XRRCrtcInfo'
> 1769 | static inline Bool isLandscapeOrientation(XRRCrtcInfo* info) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1773:30: error: use of undeclared identifier 'RR_Rotate_0'
> 1773 | return info->rotation == RR_Rotate_0 || info->rotation == RR_Rotate_180;
>       | ^
>    ... (rest of output omitted)
> 
> 
> Seems we miss some checks for the NO_XRANDR macro.

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26348#pullrequestreview-3028151108

From mbaesken at openjdk.org  Thu Jul 17 07:13:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Jul 2025 07:13:51 GMT
Subject: RFR: 8362390: AIX make fails in awt_GraphicsEnv.c
In-Reply-To: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
References: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
Message-ID: <fM2f4Lnt__HhgNen6Z7S3GGYNhaNR36UdHIsBlzDH8I=.03d7e010-2518-451e-8061-069331832fa5@github.com>

On Wed, 16 Jul 2025 12:44:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have build errors on AIX , seems related to [JDK-8354415](https://bugs.openjdk.org/browse/JDK-8354415) :
> 
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libawt_xawt_awt_GraphicsEnv.o:
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1751:43: error: unknown type name 'XRRModeInfo'
> 1751 | static jint refreshRateFromModeInfo(const XRRModeInfo *modeInfo) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1758:31: error: use of undeclared identifier 'RR_Interlace'
> 1758 | if (modeInfo->modeFlags & RR_Interlace) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1762:31: error: use of undeclared identifier 'RR_DoubleScan'
> 1762 | if (modeInfo->modeFlags & RR_DoubleScan) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1769:43: error: unknown type name 'XRRCrtcInfo'
> 1769 | static inline Bool isLandscapeOrientation(XRRCrtcInfo* info) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1773:30: error: use of undeclared identifier 'RR_Rotate_0'
> 1773 | return info->rotation == RR_Rotate_0 || info->rotation == RR_Rotate_180;
>       | ^
>    ... (rest of output omitted)
> 
> 
> Seems we miss some checks for the NO_XRANDR macro.

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/26348#issuecomment-3082881040

From mbaesken at openjdk.org  Thu Jul 17 07:13:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Jul 2025 07:13:52 GMT
Subject: Integrated: 8362390: AIX make fails in awt_GraphicsEnv.c
In-Reply-To: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
References: <my7S0hWXxNcO0kWJCFVOpMMo4AfjiBrIIy-PCmb7ZXY=.649e78dc-c0e7-468f-a215-cf148675f376@github.com>
Message-ID: <fQI-YGF7a81yCgkl348PLltArVwvF70dqFW-0-b3wvc=.4ae5ff00-7213-48dd-9128-eb6c7b457471@github.com>

On Wed, 16 Jul 2025 12:44:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have build errors on AIX , seems related to [JDK-8354415](https://bugs.openjdk.org/browse/JDK-8354415) :
> 
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libawt_xawt_awt_GraphicsEnv.o:
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1751:43: error: unknown type name 'XRRModeInfo'
> 1751 | static jint refreshRateFromModeInfo(const XRRModeInfo *modeInfo) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1758:31: error: use of undeclared identifier 'RR_Interlace'
> 1758 | if (modeInfo->modeFlags & RR_Interlace) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1762:31: error: use of undeclared identifier 'RR_DoubleScan'
> 1762 | if (modeInfo->modeFlags & RR_DoubleScan) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1769:43: error: unknown type name 'XRRCrtcInfo'
> 1769 | static inline Bool isLandscapeOrientation(XRRCrtcInfo* info) {
>       | ^
> /priv/jenkins/client-home/workspace/openjdk-jdk-aix_ppc64-opt/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c:1773:30: error: use of undeclared identifier 'RR_Rotate_0'
> 1773 | return info->rotation == RR_Rotate_0 || info->rotation == RR_Rotate_180;
>       | ^
>    ... (rest of output omitted)
> 
> 
> Seems we miss some checks for the NO_XRANDR macro.

This pull request has now been integrated.

Changeset: 18190519
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18190519e73705281adf3f94d710d000e75b1729
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8362390: AIX make fails in awt_GraphicsEnv.c

Reviewed-by: prr, serb, clanger

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

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

From psadhukhan at openjdk.org  Thu Jul 17 07:50:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 17 Jul 2025 07:50:51 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
Message-ID: <rIGx_MWIudedJeU8IMWYep5Pv7rD75ul8UJ7JBCQkzQ=.c0ad939f-f4fe-46df-a0df-b0ce1da13f12@github.com>

On Mon, 7 Jul 2025 15:27:58 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Changes protected fields to static
>  - Problem list files for Mac OS only
>  - Removes passed tests from problem list
>  - Changes Frame width to 300, uses protected constants for all base tests frame sizes

What do you mean by "focus workaround trick" and " minimizing area in the window control"? Are you seeing click is happening on the minimize button on the frame and frame getting iconified?
In that case instead of changing the frame width/height, guess you can set with `frame.setUndecorated` to have undecorated windows..Also, I have seen this test renders the frame on the top-left corner, it will be good to keep it at the center of the frame using `setLocationRelativeTo(null)`

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3082996401

From psadhukhan at openjdk.org  Thu Jul 17 08:02:48 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 17 Jul 2025 08:02:48 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize()
In-Reply-To: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
Message-ID: <qKGlzXKW-Op-riwsm4WF9FVODIg12CLo41iLtRlxi_g=.73d2a54d-5c29-4544-b422-8fb6ade283a8@github.com>

On Wed, 16 Jul 2025 20:47:23 GMT, Phil Race <prr at openjdk.org> wrote:

> Replace finalization with 2D Disposer

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 661:

> 659: 
> 660:     private static native long createNSPrintInfo();
> 661:     private static native void disposeNSPrintInfo(long printInfo);

What is the reason for using static here when it was not before?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26359#discussion_r2212602253

From psadhukhan at openjdk.org  Thu Jul 17 08:06:49 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 17 Jul 2025 08:06:49 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v3]
In-Reply-To: <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>
Message-ID: <DXg6liMusKCWSv8vXrjSX-X8BGD63cYf7waaw4oeOKg=.5bbaec3b-4abe-4d2c-a9e3-6a3d7fcf0bf2@github.com>

On Wed, 16 Jul 2025 10:34:24 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
>> Test stabilization done by requesting focus for the frame before starting the testing. 
>> 
>> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
>> CI link is added in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove build util

test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 120:

> 118:         frame.setVisible(true);
> 119:         frame.toFront();
> 120:         frame.requestFocus();

If you are particular about focus being gained before the test starts, maybe you can use `CountDownLatch `and have FocusListener for frame and  wait till timeout and  release the latch in `focusGained`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2212616108

From psadhukhan at openjdk.org  Thu Jul 17 08:26:48 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 17 Jul 2025 08:26:48 GMT
Subject: RFR: 8361524: [XWayland] possible JavaFX interop hang
In-Reply-To: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
References: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
Message-ID: <2hOwuB-P3lWvJkqmXzci9WnDjfECD8rlEIJhcw28wT8=.a8c133e8-90ab-4c0e-92b1-8c9f97330a53@github.com>

On Mon, 7 Jul 2025 21:41:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Callbacks in the `src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c` file normally have the following pattern:
> 
> 
> helper->isDone = TRUE;
> callbackEnd();
> // return;
> 
> 
> Failing to call `callbackEnd()` could result in a hang if another GTK loop is running (e.g., JavaFX see https://github.com/openjdk/jdk/pull/22131#issue-2660482472).
> 
> This fix corrects this flaw.

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26172#pullrequestreview-3028469358

From tr at openjdk.org  Thu Jul 17 10:37:51 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 17 Jul 2025 10:37:51 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v3]
In-Reply-To: <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>
Message-ID: <wEd1VZy4q2fkuQumauM2vwJr5zWwEJv03aglQ8HR4ZA=.38b8cf54-689a-476f-9aff-3d288fb8b9d6@github.com>

On Wed, 16 Jul 2025 10:34:24 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
>> Test stabilization done by requesting focus for the frame before starting the testing. 
>> 
>> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
>> CI link is added in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove build util

LGTM

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

Marked as reviewed by tr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26307#pullrequestreview-3028947088

From abhiscxk at openjdk.org  Thu Jul 17 11:15:55 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 17 Jul 2025 11:15:55 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v3]
In-Reply-To: <DXg6liMusKCWSv8vXrjSX-X8BGD63cYf7waaw4oeOKg=.5bbaec3b-4abe-4d2c-a9e3-6a3d7fcf0bf2@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>
 <DXg6liMusKCWSv8vXrjSX-X8BGD63cYf7waaw4oeOKg=.5bbaec3b-4abe-4d2c-a9e3-6a3d7fcf0bf2@github.com>
Message-ID: <5KkzZ5ROnlD2vah5FF8DD3aJPARmxSWS2lJlHbNokfg=.aa0a40dc-c457-4b6a-bcd8-7e434275845e@github.com>

On Thu, 17 Jul 2025 08:04:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove build util
>
> test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 120:
> 
>> 118:         frame.setVisible(true);
>> 119:         frame.toFront();
>> 120:         frame.requestFocus();
> 
> If you are particular about focus being gained before the test starts, maybe you can use `CountDownLatch `and have FocusListener for frame and  wait till timeout and  release the latch in `focusGained`

`CountDownlatch` should be used along with` requestFocus` ?
Otherwise, I think the test will timeout anyway because if we remove these two statements, frame may not have focus.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2213056140

From duke at openjdk.org  Thu Jul 17 17:08:13 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 17 Jul 2025 17:08:13 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v5]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <NjEnLU1Sj41VlE_g3Ypai4kKS2BZyuSFS7fPXRuqk0w=.f7fec403-f068-4dca-92b0-dad3f279ac9a@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare 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 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Changes protected fields to static
 - Problem list files for Mac OS only
 - Removes passed tests from problem list
 - Changes Frame width to 300, uses protected constants for all base tests frame sizes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/6fe853a8..3b0c2462

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

  Stats: 28415 lines in 852 files changed: 17113 ins; 5986 del; 5316 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Thu Jul 17 17:08:15 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 17 Jul 2025 17:08:15 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
Message-ID: <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>

On Mon, 7 Jul 2025 15:27:58 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Changes protected fields to static
>  - Problem list files for Mac OS only
>  - Removes passed tests from problem list
>  - Changes Frame width to 300, uses protected constants for all base tests frame sizes

In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.

I have tested with undecorated frames, but the test continues to fail. The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.

I will set the frames (The background undecorated frame, and the heavyweight component frames) on center as you have suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3084797036

From prr at openjdk.org  Thu Jul 17 21:16:04 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 17 Jul 2025 21:16:04 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize() [v2]
In-Reply-To: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
Message-ID: <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>

> Replace finalization with 2D Disposer

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

  8362452

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26359/files
  - new: https://git.openjdk.org/jdk/pull/26359/files/f054d5a8..7dcd16a8

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

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

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

From prr at openjdk.org  Thu Jul 17 21:16:04 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 17 Jul 2025 21:16:04 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize() [v2]
In-Reply-To: <1E8wOofchCVLJLhg3UJYG9zV5CZHrgYmCkjQJsHEq_0=.aa6ada46-9334-4c05-abdf-5828d6fd8680@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
 <1E8wOofchCVLJLhg3UJYG9zV5CZHrgYmCkjQJsHEq_0=.aa6ada46-9334-4c05-abdf-5828d6fd8680@github.com>
Message-ID: <zWTvlLjh-gP6LnZf3mN-IHZWyX2wt-D-dlOMHfjNnaM=.262fbfbe-fa39-48da-8b3b-0f4217245341@github.com>

On Thu, 17 Jul 2025 04:29:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8362452
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 651:
> 
>> 649: 
>> 650:         public void dispose() {
>> 651:             synchronized (lock) {
> 
> I do not think this synchronization is necessary. Before the patch it was used to guard access to fNSPrintInfo field, which might have been lazily initialized and disposed concurrently.
> 
> Now we use the Disposer only if fNSPrintInfo has been used and initialized -> we saved it to NSPrintInfoDisposer and from that point it is never changed.
> 
> So we can drop the lock, and all check for the field(seems createNSPrintInfo cannot return -1) + mark it as final

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26359#discussion_r2214323653

From prr at openjdk.org  Thu Jul 17 21:16:04 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 17 Jul 2025 21:16:04 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize() [v2]
In-Reply-To: <qKGlzXKW-Op-riwsm4WF9FVODIg12CLo41iLtRlxi_g=.73d2a54d-5c29-4544-b422-8fb6ade283a8@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
 <qKGlzXKW-Op-riwsm4WF9FVODIg12CLo41iLtRlxi_g=.73d2a54d-5c29-4544-b422-8fb6ade283a8@github.com>
Message-ID: <1yi4DSXX5AXVjxWjIfIyY2pF8tle2S8jsMiq4uMh_z8=.9bf4e598-bf61-4ce9-a08d-df77cf5ca9bd@github.com>

On Thu, 17 Jul 2025 08:00:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8362452
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 661:
> 
>> 659: 
>> 660:     private static native long createNSPrintInfo();
>> 661:     private static native void disposeNSPrintInfo(long printInfo);
> 
> What is the reason for using static here when it was not before?

because it has no need for the instance and moreover it can't be called on the instance because that would mean it is still reachable.
It is called instead from the disposer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26359#discussion_r2214310791

From prr at openjdk.org  Thu Jul 17 21:22:51 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 17 Jul 2025 21:22:51 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <FPCAlqcKQK2wnojZDh4deK68fxmiUtWhvUXzys2Foaw=.a7f563e4-7e29-46ec-97da-6307097f58fc@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <KOPJ6k4qDUFYdIBJrExPysmQYPyZHtO81yLlvwjyaUo=.95b5527e-403e-4274-8aa6-3b4b95062c63@github.com>
 <W5AhemC_BCQ6emEIzYH-evy1gzqHdT0cu6nQtkLVc-4=.148b59e9-2032-4282-9955-8e45a56f5f9f@github.com>
 <wh5FY46Jdi_keoyVDm6lg4SKBi165YSM_Yk4_Ybe5fU=.2b827f8d-cf16-4163-9588-64fdacbc3706@github.com>
 <yDdR01gzJQNDTcG4f3ADm6KMlt4EFzVgCeBqZ3S_jmE=.2fe0e349-a0fa-498d-9132-3cb5b17f77fd@github.com>
 <FPCAlqcKQK2wnojZDh4deK68fxmiUtWhvUXzys2Foaw=.a7f563e4-7e29-46ec-97da-6307097f58fc@github.com>
Message-ID: <PVCSQhousH8yZbxeOa05xY6UePS66RmO3Gxh5qdKzzU=.d9332ec8-0172-4b24-9e11-7e7abb02e70d@github.com>

On Thu, 17 Jul 2025 05:42:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I think that's right. At first I thought you were referring to the constructor of the thing that wants to use the cleaner, but you mean the constructor of the Cleanable itself may be still under construction when the referent is collected and installing the reachabilityFence at the end of the constructor prevents that.
>
> I tried to compare how Cleaner and Disposer are used. I found that in most cases Cleaner uses `this` as the object to track. But Disposer often uses a separate object like disposerReferent or some kind of anchor. This patch is one example. In some places we even replaced this with a different object. You can see that in the following RFR:
> https://bugs.openjdk.org/browse/JDK-8030099
> https://mail.openjdk.org/pipermail/swing-dev/2015-October/005053.html
> 
> I think I found the reason: https://bugs.openjdk.org/browse/JDK-8071507
> 
> In older versions of the JDK the Disposer had to use phantom references. Phantom references allow native cleanup to happen after the object is 100% no longer reachable. But this had a problem, the object stayed in memory until the reference was added to the queue and the code called [clear](https://github.com/openjdk/jdk/blob/bc72f476d1281dae2adb2322004c9880c1a6b66c/src/java.desktop/share/classes/sun/java2d/Disposer.java#L134).
> 
> To avoid keeping large AWT or Java2D objects in memory for too long the code used small helper objects as referents instead of using the real object.
> 
> Now the problem described in JDK-8071507 is fixed. So maybe we no longer need to use small disposer referents. And you can check that by the test from the description of this PR.

I know this is possible, but I'd prefer to keep this pattern. This way It is crystal clear that nothing to do with reference queues etc are delaying the GC from immediately reclaiming the memory.
Honestly, it probably matters not so much for JRSUIControls, and even less so for CGraphicsEnvironment, but may matter for some other cases. 

A later follow-up fix could go change a whole bunch of these cases at once and we'd then have a good reference (pun intended) as to whether any issues showed up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2214335276

From prr at openjdk.org  Thu Jul 17 21:25:08 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 17 Jul 2025 21:25:08 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v4]
In-Reply-To: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
Message-ID: <VfsWAXSruKUY7P4cVRrrb-JwvMWJwzsCysEk2r3haU8=.bc40fdd5-fee6-4214-9d31-f25fed068a97@github.com>

> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
> 
> I don't see a way to add a test to verify this clean up.

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

  8362291

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26332/files
  - new: https://git.openjdk.org/jdk/pull/26332/files/5e9d55ff..3a5b6812

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

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

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

From prr at openjdk.org  Thu Jul 17 21:25:09 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 17 Jul 2025 21:25:09 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v3]
In-Reply-To: <Q-6SMlvHJ4FyExRyPzPfj_8iIpmdVDVYYwW0RLqHB9s=.7f414c33-e08a-4446-a4c4-01eb79190522@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <vLJ6o61DqAU_j1T7143pMYpVcAHyEKaj_ISpxUEZYgw=.f1f8c75e-2187-40b5-a360-3c6bc776eca3@github.com>
 <Q-6SMlvHJ4FyExRyPzPfj_8iIpmdVDVYYwW0RLqHB9s=.7f414c33-e08a-4446-a4c4-01eb79190522@github.com>
Message-ID: <k5LeOsRR6TFyUcHnsQSBzFtCIGHCw66k31t3_hI716M=.9e684bb3-cf61-4648-a021-5a524e73c969@github.com>

On Thu, 17 Jul 2025 00:32:34 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8362291
>
> src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 98:
> 
>> 96:     /** Reference to the display reconfiguration callback context. */
>> 97:     private final long displayReconfigContext;
>> 98:     private Object disposerReferent = new Object();
> 
> `disposerReferent` can be final

ok

> src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 147:
> 
>> 145: 
>> 146:     private static class CGEDisposerRecord implements DisposerRecord {
>> 147:         private long displayReconfigContext;
> 
> `displayReconfigContext` should be final

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2214338709
PR Review Comment: https://git.openjdk.org/jdk/pull/26332#discussion_r2214338552

From prr at openjdk.org  Thu Jul 17 21:35:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 17 Jul 2025 21:35:00 GMT
Subject: RFR: 8362557: [macOS] Remove CFont.finalize()
Message-ID: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>

Replace CFont.finalize() with a disposer.

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

Commit messages:
 - 8362557

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

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

From serb at openjdk.org  Thu Jul 17 22:22:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 17 Jul 2025 22:22:50 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <PVCSQhousH8yZbxeOa05xY6UePS66RmO3Gxh5qdKzzU=.d9332ec8-0172-4b24-9e11-7e7abb02e70d@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <npa1a2TYiDPYjptOCAUiDU6Is3e-_03TxGfY1y5u5No=.6ce6fa8d-e234-4cc7-a0f7-ff8a39fbb884@github.com>
 <KOPJ6k4qDUFYdIBJrExPysmQYPyZHtO81yLlvwjyaUo=.95b5527e-403e-4274-8aa6-3b4b95062c63@github.com>
 <W5AhemC_BCQ6emEIzYH-evy1gzqHdT0cu6nQtkLVc-4=.148b59e9-2032-4282-9955-8e45a56f5f9f@github.com>
 <wh5FY46Jdi_keoyVDm6lg4SKBi165YSM_Yk4_Ybe5fU=.2b827f8d-cf16-4163-9588-64fdacbc3706@github.com>
 <yDdR01gzJQNDTcG4f3ADm6KMlt4EFzVgCeBqZ3S_jmE=.2fe0e349-a0fa-498d-9132-3cb5b17f77fd@github.com>
 <FPCAlqcKQK2wnojZDh4deK68fxmiUtWhvUXzys2Foaw=.a7f563e4-7e29-46ec-97da-6307097f58fc@github.com>
 <PVCSQhousH8yZbxeOa05xY6UePS66RmO3Gxh5qdKzzU=.d9332ec8-0172-4b24-9e11-7e7abb02e70d@github.com>
Message-ID: <zGoDN63Y3kwMlqibj9YNI2XmahTcY4UDF9PAGWG6SMM=.eccce815-4911-447a-94cf-ac5950efe8c1@github.com>

On Thu, 17 Jul 2025 21:20:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> I tried to compare how Cleaner and Disposer are used. I found that in most cases Cleaner uses `this` as the object to track. But Disposer often uses a separate object like disposerReferent or some kind of anchor. This patch is one example. In some places we even replaced this with a different object. You can see that in the following RFR:
>> https://bugs.openjdk.org/browse/JDK-8030099
>> https://mail.openjdk.org/pipermail/swing-dev/2015-October/005053.html
>> 
>> I think I found the reason: https://bugs.openjdk.org/browse/JDK-8071507
>> 
>> In older versions of the JDK the Disposer had to use phantom references. Phantom references allow native cleanup to happen after the object is 100% no longer reachable. But this had a problem, the object stayed in memory until the reference was added to the queue and the code called [clear](https://github.com/openjdk/jdk/blob/bc72f476d1281dae2adb2322004c9880c1a6b66c/src/java.desktop/share/classes/sun/java2d/Disposer.java#L134).
>> 
>> To avoid keeping large AWT or Java2D objects in memory for too long the code used small helper objects as referents instead of using the real object.
>> 
>> Now the problem described in JDK-8071507 is fixed. So maybe we no longer need to use small disposer referents. And you can check that by the test from the description of this PR.
>
> I know this is possible, but I'd prefer to keep this pattern. This way It is crystal clear that nothing to do with reference queues etc are delaying the GC from immediately reclaiming the memory.
> Honestly, it probably matters not so much for JRSUIControls, and even less so for CGraphicsEnvironment, but may matter for some other cases. 
> 
> A later follow-up fix could go change a whole bunch of these cases at once and we'd then have a good reference (pun intended) as to whether any issues showed up.

sounds good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26331#discussion_r2214413658

From serb at openjdk.org  Thu Jul 17 22:23:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 17 Jul 2025 22:23:50 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v4]
In-Reply-To: <VfsWAXSruKUY7P4cVRrrb-JwvMWJwzsCysEk2r3haU8=.bc40fdd5-fee6-4214-9d31-f25fed068a97@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <VfsWAXSruKUY7P4cVRrrb-JwvMWJwzsCysEk2r3haU8=.bc40fdd5-fee6-4214-9d31-f25fed068a97@github.com>
Message-ID: <cSS1sbzrmzU9ontJwvjdXoQR8JwrpCT-AaZ5Tzwr0cM=.4aa86735-d1d1-4ab8-8590-29c3b45cf994@github.com>

On Thu, 17 Jul 2025 21:25:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
>> 
>> I don't see a way to add a test to verify this clean up.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362291

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26332#pullrequestreview-3031184398

From bchristi at openjdk.org  Thu Jul 17 23:56:47 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 17 Jul 2025 23:56:47 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
Message-ID: <fqI3XueskslMAT51TDJAhiYXTKpLpgespBRa4yP_N94=.7a67545f-62cb-44a9-a024-3c6ae8b6b0da@github.com>

On Wed, 16 Jul 2025 22:45:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Eliminate a finalize() method in the Swing macOS implementation.
>> 
>> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
>> 
>> import javax.swing.JTabbedPane;
>> import javax.swing.plaf.TabbedPaneUI;
>> 
>> public class CreateTabbedPaneUIStressTest {
>> 
>>    public static void main(String[] args) {
>>        for (int i=0; i<1000000000; i++) {
>>            JTabbedPane jtp = new JTabbedPane();
>>            TabbedPaneUI tpui = jtp.getUI();
>>        }
>>    }
>> }
>> 
>> 
>> I also monitored the process size using 'top'.
>> And when I commented out the native call that did the free and re-tested I saw process size grow.
>> 
>> Turning the above into a useful regression test doesn't seem possible to me.
>> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JRSUIControl.java

I would recommend adding a `reachabiltyFence()` to `Disposer.addRecord()`, as @mrserb [suggests](https://github.com/openjdk/jdk/pull/26331/files#r2208586134).

Unexpected unreachability is a subtle problem with GC-assisted APIs - finalizers, `Cleaner`, and even direct use of `References` & `ReferenceQueues`. In particular, the VM can decide than object is unreachable even when a method on that object is still running.

For this reason, our standard recommendation is that any instance method that accesses the cleanable state (in this case, `cfDictionaryPtr`) should be enclosed with a `try{...}finally{ reachabilityFence(); }` block.

Synchronized methods _might_ be OK without, but the following methods are not synchronized, and access `cfDictionaryPtr`:
* `getHitForPoint()` 
* `getPartBounds()`
* `getScrollBarOffsetChange()`
* `sync()`

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

Changes requested by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26331#pullrequestreview-3031319703

From serb at openjdk.org  Fri Jul 18 03:12:47 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 18 Jul 2025 03:12:47 GMT
Subject: RFR: 8362557: [macOS] Remove CFont.finalize()
In-Reply-To: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>
References: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>
Message-ID: <zL8qez4pvIe_q0KiCnpiSej_QaFsrnkhsECyEpMfT4o=.a994ea33-010a-4d83-a39e-f28ed9c4fbee@github.com>

On Thu, 17 Jul 2025 21:30:10 GMT, Phil Race <prr at openjdk.org> wrote:

> Replace CFont.finalize() with a disposer.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26373#pullrequestreview-3031652098

From serb at openjdk.org  Fri Jul 18 03:14:47 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 18 Jul 2025 03:14:47 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize() [v2]
In-Reply-To: <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
 <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>
Message-ID: <4oXMLrt3WzBekHRpiJ3QCyBb91ZZBYbisJjAAUeggiA=.4b1d20a7-da20-4df9-b7ae-10094f3b2574@github.com>

On Thu, 17 Jul 2025 21:16:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Replace finalization with 2D Disposer
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362452

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26359#pullrequestreview-3031654126

From psadhukhan at openjdk.org  Fri Jul 18 03:25:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 18 Jul 2025 03:25:52 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize() [v2]
In-Reply-To: <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
 <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>
Message-ID: <7_hzZQ4cilTY25Jzd7EfhP7R_q7ApOgOF55AuhSdwc8=.c80311a8-784b-4a71-81d7-572ad7211ba4@github.com>

On Thu, 17 Jul 2025 21:16:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Replace finalization with 2D Disposer
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362452

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26359#pullrequestreview-3031664986

From psadhukhan at openjdk.org  Fri Jul 18 03:29:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 18 Jul 2025 03:29:55 GMT
Subject: RFR: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu [v3]
In-Reply-To: <5KkzZ5ROnlD2vah5FF8DD3aJPARmxSWS2lJlHbNokfg=.aa0a40dc-c457-4b6a-bcd8-7e434275845e@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
 <-4a58hq-F-OHioZRkL48juF8jrBwdeX3wZS6f-2GJgs=.5a605a7d-9bfb-46b4-a440-10d0299b83ad@github.com>
 <DXg6liMusKCWSv8vXrjSX-X8BGD63cYf7waaw4oeOKg=.5bbaec3b-4abe-4d2c-a9e3-6a3d7fcf0bf2@github.com>
 <5KkzZ5ROnlD2vah5FF8DD3aJPARmxSWS2lJlHbNokfg=.aa0a40dc-c457-4b6a-bcd8-7e434275845e@github.com>
Message-ID: <6tjq_mxCdQ9qjq0TutmU2JDs0t9DhjQRWGrLavzd6-E=.4bb06d2b-8adc-4f76-953a-93894b1511f4@github.com>

On Thu, 17 Jul 2025 11:12:56 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java line 120:
>> 
>>> 118:         frame.setVisible(true);
>>> 119:         frame.toFront();
>>> 120:         frame.requestFocus();
>> 
>> If you are particular about focus being gained before the test starts, maybe you can use `CountDownLatch `and have FocusListener for frame and  wait till timeout and  release the latch in `focusGained`
>
> `CountDownlatch` should be used along with` requestFocus` ?
> Otherwise, I think the test may timeout because if we remove these two statements, frame may not have focus.

Yes as the requestFocus spec says "Developers must never assume that this Component is the focus owner until this Component receives a FOCUS_GAINED event"
but I guess the present change is good enough for now since there is robot delay and all..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26307#discussion_r2214794102

From psadhukhan at openjdk.org  Fri Jul 18 03:31:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 18 Jul 2025 03:31:47 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize() [v2]
In-Reply-To: <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
 <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>
Message-ID: <TM0k6E99KUZFaGjdxsVtaffEoeyhgtlbWAPKKPh6F90=.6fa066de-46d0-4fee-97d9-931708ddf97b@github.com>

On Thu, 17 Jul 2025 21:16:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Replace finalization with 2D Disposer
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362452

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java line 639:

> 637:     // The following methods are CPrinterJob specific.
> 638: 
> 639:     static class NSPrintInfoDisposer implements DisposerRecord {

probably we can make it "private"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26359#discussion_r2214796435

From serb at openjdk.org  Fri Jul 18 03:37:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 18 Jul 2025 03:37:49 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
Message-ID: <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>

On Wed, 16 Jul 2025 22:45:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Eliminate a finalize() method in the Swing macOS implementation.
>> 
>> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
>> 
>> import javax.swing.JTabbedPane;
>> import javax.swing.plaf.TabbedPaneUI;
>> 
>> public class CreateTabbedPaneUIStressTest {
>> 
>>    public static void main(String[] args) {
>>        for (int i=0; i<1000000000; i++) {
>>            JTabbedPane jtp = new JTabbedPane();
>>            TabbedPaneUI tpui = jtp.getUI();
>>        }
>>    }
>> }
>> 
>> 
>> I also monitored the process size using 'top'.
>> And when I commented out the native call that did the free and re-tested I saw process size grow.
>> 
>> Turning the above into a useful regression test doesn't seem possible to me.
>> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JRSUIControl.java

Marked as reviewed by serb (Reviewer).

>Synchronized methods might be OK without, but the following methods are not synchronized, and access cfDictionaryPtr:

Unfortunately this is actually true, in awt we even have a special class [CFRetainedResource](https://github.com/openjdk/jdk/blob/04c0b130f09c093797895cc928fe020d7e584cb9/src/java.desktop/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java#L36) which maintains a locks around the native pointer and prevents its usage after de-allocation(intentional or via finalize). It was implemented as part of JDK-8164143.

I can migrate the current API of DIsposer to the something similar to CFRetainedResource as a follow up bug. The current one did not introduce the new issues, since implementation via finalize has the same bug.

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

PR Review: https://git.openjdk.org/jdk/pull/26331#pullrequestreview-3031678484
PR Comment: https://git.openjdk.org/jdk/pull/26331#issuecomment-3086587833

From psadhukhan at openjdk.org  Fri Jul 18 03:39:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 18 Jul 2025 03:39:47 GMT
Subject: RFR: 8362557: [macOS] Remove CFont.finalize()
In-Reply-To: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>
References: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>
Message-ID: <WXjvFloZUolHwmBf720f9idH1jCFNELp0KPgJGtScC0=.a64b072d-afb8-4f7b-a326-60e0540fec8a@github.com>

On Thu, 17 Jul 2025 21:30:10 GMT, Phil Race <prr at openjdk.org> wrote:

> Replace CFont.finalize() with a disposer.

Please update the copyright year..

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26373#pullrequestreview-3031680013

From psadhukhan at openjdk.org  Fri Jul 18 04:03:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 18 Jul 2025 04:03:47 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
 <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>
Message-ID: <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>

On Thu, 17 Jul 2025 17:04:25 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.

WHich test in particular? or is it all tests have this behavior?

> The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.

I tried JMenuBarOverlapping.java but I dont see any click on title bar..The cursor in on top-left of "Test Menu" menu..
If clicking on the title bar is needed to make it gain focus, probably you can try with calling `frame.requestFocus` and use `CountDownLatch `with timeout to wait till FOCUS_GAINED event is received and release the latch in `focusGained()` and then start the test

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3086636739

From kizune at openjdk.org  Fri Jul 18 05:49:50 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 18 Jul 2025 05:49:50 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v4]
In-Reply-To: <VfsWAXSruKUY7P4cVRrrb-JwvMWJwzsCysEk2r3haU8=.bc40fdd5-fee6-4214-9d31-f25fed068a97@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <VfsWAXSruKUY7P4cVRrrb-JwvMWJwzsCysEk2r3haU8=.bc40fdd5-fee6-4214-9d31-f25fed068a97@github.com>
Message-ID: <dhv_tkhvhzQaA9w_SLZ7uiU2DgxJoSDt5EEG0NeH8Oc=.ebc81dda-0cee-4c3f-b3b3-34099d742bf4@github.com>

On Thu, 17 Jul 2025 21:25:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
>> 
>> I don't see a way to add a test to verify this clean up.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362291

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26332#pullrequestreview-3031937046

From kizune at openjdk.org  Fri Jul 18 05:50:00 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 18 Jul 2025 05:50:00 GMT
Subject: RFR: 8362557: [macOS] Remove CFont.finalize()
In-Reply-To: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>
References: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>
Message-ID: <iEDl07n2MG9y8NvIZUgLJf5cjC7AQ9jbZf6CjQhErYE=.6fc396f7-5cb1-4018-a448-488c95a9f9f9@github.com>

On Thu, 17 Jul 2025 21:30:10 GMT, Phil Race <prr at openjdk.org> wrote:

> Replace CFont.finalize() with a disposer.

LGTM

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26373#pullrequestreview-3031933694

From kizune at openjdk.org  Fri Jul 18 05:51:49 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 18 Jul 2025 05:51:49 GMT
Subject: RFR: 8361283: [Accessibility, macOS,
 VoiceOver] VoiceOver announced
 Tab items of JTabbedPane as RadioButton on macOS [v4]
In-Reply-To: <PxraFDnGTaBbv8TKEkJYLR97I95Whzhmf8oWXb9f4bc=.fde406a7-7736-4fa7-a820-d3ff80b96c44@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
 <PxraFDnGTaBbv8TKEkJYLR97I95Whzhmf8oWXb9f4bc=.fde406a7-7736-4fa7-a820-d3ff80b96c44@github.com>
Message-ID: <SGcyFJnzVEH7RCJiP7A7VjI0z9jzicE7v7CL83o0FTU=.cd689884-e1b3-4302-91c9-13ca2ac678ae@github.com>

On Mon, 14 Jul 2025 08:36:57 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> **Issue** : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
>> 
>> **Analysis** : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
>> 
>> **Proposed Fix** : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.
>> 
>> **Testing** : Manual test case has been added to verify the fix.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Role description code moved to TabButtonAccessibility

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26096#pullrequestreview-3031944047

From kizune at openjdk.org  Fri Jul 18 05:52:52 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 18 Jul 2025 05:52:52 GMT
Subject: RFR: 8362452: [macOS] Remove CPrinterJob.finalize() [v2]
In-Reply-To: <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
 <Q9UfhBQeM1cBKRxfVLmb1C2E9POFfGVTjD0jFNzhBUI=.4b1f914f-2199-41d0-a04d-d19acb37e4a0@github.com>
Message-ID: <Llw04OypmB3hpWQgQTqbv-z8UFv9BLHTxz7cx6IatEU=.d3105a4b-9768-4c6f-8222-1a5a230718ae@github.com>

On Thu, 17 Jul 2025 21:16:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Replace finalization with 2D Disposer
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362452

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26359#pullrequestreview-3031939286

From abhiscxk at openjdk.org  Fri Jul 18 06:15:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 18 Jul 2025 06:15:56 GMT
Subject: Integrated: 8338282:
 javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and
 Ubuntu
In-Reply-To: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
References: <K-0jY2D_EnJotNCNS42KdXgoXbGyLZ88aYckrCBksEU=.2c07c800-80db-4255-bc0f-848545e1ff57@github.com>
Message-ID: <kKcp-kwDSQiA7-Hacy79GhApBhKqURKLdceG8gO59hw=.dcc609b4-3804-46ec-babf-2816bcb62918@github.com>

On Tue, 15 Jul 2025 05:40:17 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test is failing on intermittently on macOS and ubuntu machine in CI testing.
> Test stabilization done by requesting focus for the frame before starting the testing. 
> 
> Ran the test before and after the fix and there is no failure after test stabilization for multiple run.
> CI link is added in JBS.

This pull request has now been integrated.

Changeset: 4e0b0358
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e0b03580d3764e06ec65493143e80c291fa3fbb
Stats:     4 lines in 1 file changed: 2 ins; 1 del; 1 mod

8338282: javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java test failed on macOS and Ubuntu

Reviewed-by: tr, dnguyen, serb

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

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

From abhiscxk at openjdk.org  Fri Jul 18 06:15:56 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 18 Jul 2025 06:15:56 GMT
Subject: Integrated: 8361283: [Accessibility,macOS,VoiceOver] VoiceOver
 announced Tab items of JTabbedPane as RadioButton on macOS
In-Reply-To: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
References: <6jMm5x7hnGxZ9tVAy4OkRgVRj4SoTbgIgmlbkHjczgE=.4ef3d937-fb01-472b-9a80-730e9cc48797@github.com>
Message-ID: <tVBckqxpIJ57HPZ2fLcXN4kB2SOkCF74X8lKyPGSVzA=.a58177b7-1a58-4bf0-9536-5c6decebe90f@github.com>

On Wed, 2 Jul 2025 15:05:27 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> **Issue** : VO doesn't announce Tab items of a JTabbedPane as RadioButton which is wrong. 
> 
> **Analysis** : That is due to the role mapping of tab items as `NSAccessibilityRadioButtonRole` in `JavaAccessibilityUtilities.m` file. Since the accessibility role description is fetched in `accessibilityRoleDescription` API if `CommonComponentAccessiblity.m` file, the sub-role passed as a parameter is `nil`, returned value is RadioButton..
> 
> **Proposed Fix** : Fix is to get the correct accessibility role description from Appkit, we should pass `NSAccessibilityTabButtonSubrole` in the subrole parameter and that returns the accessibility role as `Tab` and is announced correctly by VO.
> 
> **Testing** : Manual test case has been added to verify the fix.

This pull request has now been integrated.

Changeset: a23987fe
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a23987fecbddeea9828a9443dddd7bf8f9f0d05d
Stats:     95 lines in 3 files changed: 93 ins; 0 del; 2 mod

8361283: [Accessibility,macOS,VoiceOver] VoiceOver announced Tab items of JTabbedPane as RadioButton on macOS

Reviewed-by: asemenov, kizune

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

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

From duke at openjdk.org  Fri Jul 18 08:14:48 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 18 Jul 2025 08:14:48 GMT
Subject: RFR: 8361190: Test
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java fails on MacOS X
In-Reply-To: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
References: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
Message-ID: <3NnGZljkl_7n671ESgZ9bZM4Kz7qZEpA0M4Yk5H_L7U=.241d7e1c-a061-4602-9c30-b577bcb0df7e@github.com>

On Tue, 8 Jul 2025 16:34:31 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Add more timeout for the test to pass.

I will combine this PR with #26162 and i will see if other PRs could be merged as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/26196#issuecomment-3088279588

From myankelevich at openjdk.org  Fri Jul 18 11:35:49 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Fri, 18 Jul 2025 11:35:49 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v5]
In-Reply-To: <NjEnLU1Sj41VlE_g3Ypai4kKS2BZyuSFS7fPXRuqk0w=.f7fec403-f068-4dca-92b0-dad3f279ac9a@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <NjEnLU1Sj41VlE_g3Ypai4kKS2BZyuSFS7fPXRuqk0w=.f7fec403-f068-4dca-92b0-dad3f279ac9a@github.com>
Message-ID: <91CBlK1dprGoVqbqHRvce3nZIjLRWHzEfVTdkXFV0ow=.3822fdbe-d2ec-46d6-8c75-955a3adedd5f@github.com>

On Thu, 17 Jul 2025 17:08:13 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare 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 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Changes protected fields to static
>  - Problem list files for Mac OS only
>  - Removes passed tests from problem list
>  - Changes Frame width to 300, uses protected constants for all base tests frame sizes

Minor: could you please update the copyright years?

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3089174238

From duke at openjdk.org  Fri Jul 18 12:42:42 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 18 Jul 2025 12:42:42 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v6]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <dV0mpMlLY9TCmSTsp2OubV7W1D6ePatY0IBT1SU75iU=.36e8be54-e3ee-4f09-9d7c-5b27cb6687bc@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare 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 eight additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Changes protected fields to static
 - Problem list files for Mac OS only
 - Removes passed tests from problem list
 - Changes Frame width to 300, uses protected constants for all base tests frame sizes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/3b0c2462..35cf3e5b

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

  Stats: 205 lines in 15 files changed: 104 ins; 49 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Fri Jul 18 13:19:10 2025
From: duke at openjdk.org (Christian Heilmann)
Date: Fri, 18 Jul 2025 13:19:10 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
Message-ID: <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>

> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS.
> 
> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m.

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

 - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
 - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
 - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266
 - Merge branch 'master' into pr/11266
 - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11266/files
  - new: https://git.openjdk.org/jdk/pull/11266/files/8cd4ae4c..857a3781

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

  Stats: 4297774 lines in 34766 files changed: 2120315 ins; 1506225 del; 671234 mod
  Patch: https://git.openjdk.org/jdk/pull/11266.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11266/head:pull/11266

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

From duke at openjdk.org  Fri Jul 18 14:13:51 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 18 Jul 2025 14:13:51 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v6]
In-Reply-To: <dV0mpMlLY9TCmSTsp2OubV7W1D6ePatY0IBT1SU75iU=.36e8be54-e3ee-4f09-9d7c-5b27cb6687bc@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <dV0mpMlLY9TCmSTsp2OubV7W1D6ePatY0IBT1SU75iU=.36e8be54-e3ee-4f09-9d7c-5b27cb6687bc@github.com>
Message-ID: <55lb1FpC6bCEHeKchNKh7SABrvCG34yyK4R6Saz-xTg=.c7667fe6-7f33-427a-bd95-30e828f81abc@github.com>

On Fri, 18 Jul 2025 12:42:42 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare 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 eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Changes protected fields to static
>  - Problem list files for Mac OS only
>  - Removes passed tests from problem list
>  - Changes Frame width to 300, uses protected constants for all base tests frame sizes

I will update copyright years for changed classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3089608725

From duke at openjdk.org  Fri Jul 18 14:13:49 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Fri, 18 Jul 2025 14:13:49 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
 <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>
 <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
Message-ID: <U8y4jyhZ4I8o8J0eW_isOQEI9nONdoYCk4OCzOxSygY=.41ae9497-ae42-47e9-a5f4-84584fbc797f@github.com>

On Fri, 18 Jul 2025 04:00:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
>> 
>> I have tested with undecorated frames, but the test continues to fail. The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
>> 
>> I will set the frames (The background undecorated frame, and the heavyweight component frames) on center as you have suggested.
>
>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
> 
> WHich test in particular? or is it all tests have this behavior?
> 
>> The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
> 
> I tried JMenuBarOverlapping.java but I dont see any click on title bar..The cursor in on top-left of "Test Menu" menu..
> If clicking on the title bar is needed to make it gain focus, probably you can try with calling `frame.requestFocus` and use `CountDownLatch `with timeout to wait till FOCUS_GAINED event is received and release the latch in `focusGained()` and then start the test

@prsadhuk I have reviewed the code again and I can point out where we do have the workaround click. It can be found in class SimpleOverlappingTestBase, in method performTest. Following is an excerpt of the source code:


/* this is a workaround for certain jtreg(?) focus issue:
           tests fail starting after failing mixing tests but always pass alone.
         */
        JFrame ancestor = (JFrame)(testedComponent.getTopLevelAncestor());
        if( ancestor != null ) {
            Point ancestorLoc = ancestor.getLocationOnScreen();
            ancestorLoc.translate(isOel7orLater() ? 5 :
                                             ancestor.getWidth() / 2 - 15, 2);
            robot.mouseMove(ancestorLoc.x, ancestorLoc.y);
            Util.waitForIdle(robot);
            robot.mousePress(InputEvent.BUTTON1_MASK);
            robot.delay(50);
            robot.mouseRelease(InputEvent.BUTTON1_MASK);
            Util.waitForIdle(robot);
        }


I will use requestFocus as you have suggested and see if I get tests to pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3089604981

From serb at openjdk.org  Fri Jul 18 17:00:21 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 18 Jul 2025 17:00:21 GMT
Subject: RFR: 8359380: Rework deferral profile logic after JDK-8346465
In-Reply-To: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
References: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
Message-ID: <78xSAthz5fWJ6h8EY1K1mE9EkyfHHlNzRRIHcn3sfi4=.332b788b-7bc7-442b-88e0-440365f85fae@github.com>

On Tue, 8 Jul 2025 05:26:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.
> 
> After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.
> 
> This patch includes two changes:
> 
> 1.  We [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.
> 
> 2.  While implementing the logic above I noticed a [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I?ve added a new test case that specifically verifies this behavior.

@honkar-jdk please take a look

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

PR Comment: https://git.openjdk.org/jdk/pull/26179#issuecomment-3087560800

From serb at openjdk.org  Fri Jul 18 17:35:42 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 18 Jul 2025 17:35:42 GMT
Subject: RFR: 8361524: [XWayland] possible JavaFX interop hang
In-Reply-To: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
References: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
Message-ID: <QsEVDq5mZpzkZ4q07b2neUOPcDznXluGrFlxWMnxGmU=.38a79bbd-5905-4e3b-91d3-904dabeb7666@github.com>

On Mon, 7 Jul 2025 21:41:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Callbacks in the `src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c` file normally have the following pattern:
> 
> 
> helper->isDone = TRUE;
> callbackEnd();
> // return;
> 
> 
> Failing to call `callbackEnd()` could result in a hang if another GTK loop is running (e.g., JavaFX see https://github.com/openjdk/jdk/pull/22131#issue-2660482472).
> 
> This fix corrects this flaw.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26172#pullrequestreview-3034308682

From dnguyen at openjdk.org  Fri Jul 18 18:27:49 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 18 Jul 2025 18:27:49 GMT
Subject: RFR: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
Message-ID: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>

This test only fails in the automated portion on Windows with Nimbus LAF. The failure message is always that the leading cell is not aligned, but I see no obvious issues with the UI when testing myself. The test fails in older JDK versions as well. The original test relies on applet and cannot be run exactly, but this test was previously converted to remove all applet usage in [JDK-8354695](https://bugs.openjdk.org/browse/JDK-8354695). Since this test still fails on older JDKs and is not a regression, I chose to skip the test specifically for Nimbus LAF. I suspect this is better than ProblemListing the test for Windows since the test only fails on Windows if Nimbus LAF is used.

I also removed the automated failing of the test to allow the user to see the failure message before the test closes. Test instructions are updated to align with this.

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

Commit messages:
 - Remove title
 - Update test to show failure message and skip Nimbus.
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - Merge branch 'master' of github.com:DamonGuy/jdk
 - ... and 1 more: https://git.openjdk.org/jdk/compare/a377773f...735b44ff

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

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

From psadhukhan at openjdk.org  Fri Jul 18 18:27:50 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 18 Jul 2025 18:27:50 GMT
Subject: RFR: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
In-Reply-To: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
References: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
Message-ID: <V2RwVfV4XBSb2-dE2uOTD9QY50ehgAh1qBjPtbWfQgg=.97774559-f939-49c8-97d8-eb026aae17b4@github.com>

On Mon, 7 Jul 2025 16:51:58 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This test only fails in the automated portion on Windows with Nimbus LAF. The failure message is always that the leading cell is not aligned, but I see no obvious issues with the UI when testing myself. The test fails in older JDK versions as well. The original test relies on applet and cannot be run exactly, but this test was previously converted to remove all applet usage in [JDK-8354695](https://bugs.openjdk.org/browse/JDK-8354695). Since this test still fails on older JDKs and is not a regression, I chose to skip the test specifically for Nimbus LAF. I suspect this is better than ProblemListing the test for Windows since the test only fails on Windows if Nimbus LAF is used.
> 
> I also removed the automated failing of the test to allow the user to see the failure message before the test closes. Test instructions are updated to align with this.

What exactly is the failure thrown in Nimbus L&F? JBS says `PassFailJFrame.forceFail `is called
>From my running it seems the failure is `"java.lang.RuntimeException: leading cell is not aligned"`
It can be a genuine issue for Nimbus since it behaves ok for other L&F..

ANyways, add the bugid to this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/26165#issuecomment-3048801821
PR Comment: https://git.openjdk.org/jdk/pull/26165#issuecomment-3082229021

From psadhukhan at openjdk.org  Fri Jul 18 18:27:50 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 18 Jul 2025 18:27:50 GMT
Subject: RFR: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
In-Reply-To: <HL7C1P-P1cPx5Wcqj8YF_NaINgr2ea6fLoFeX4vy07o=.c52c3796-b395-47d6-bdcd-09e86a0a119c@github.com>
References: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
 <V2RwVfV4XBSb2-dE2uOTD9QY50ehgAh1qBjPtbWfQgg=.97774559-f939-49c8-97d8-eb026aae17b4@github.com>
 <HL7C1P-P1cPx5Wcqj8YF_NaINgr2ea6fLoFeX4vy07o=.c52c3796-b395-47d6-bdcd-09e86a0a119c@github.com>
Message-ID: <yaK9OSeq3upNWI9d8wBcrA9hfYV9CzXcez_83i0P9ZM=.1bdbe824-37af-4145-a327-0c790da9f66c@github.com>

On Mon, 14 Jul 2025 23:18:06 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> > What exactly is the failure thrown in Nimbus L&F? JBS says `PassFailJFrame.forceFail `is called From my running it seems the failure is `"java.lang.RuntimeException: leading cell is not aligned"` It can be a genuine issue for Nimbus since it behaves ok for other L&F..
> 
> I ran into the same issue when I previously checked this. I can submit a Nimbus issue afterwards if needed. Wanted to handle the test here first.

But you are handling the test failure by just omitting Nimbus run, which is not the way to go about it in my opinion..

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

PR Comment: https://git.openjdk.org/jdk/pull/26165#issuecomment-3082225526

From tr at openjdk.org  Fri Jul 18 18:27:51 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 18 Jul 2025 18:27:51 GMT
Subject: RFR: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
In-Reply-To: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
References: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
Message-ID: <4Bvx3CSBb5gUCOCix3skCjJ-e5bmyWr9rTvSSRyRkd8=.5ebb7658-e20e-46e5-a92b-6a53d34488f6@github.com>

On Mon, 7 Jul 2025 16:51:58 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> This test only fails in the automated portion on Windows with Nimbus LAF. The failure message is always that the leading cell is not aligned, but I see no obvious issues with the UI when testing myself. The test fails in older JDK versions as well. The original test relies on applet and cannot be run exactly, but this test was previously converted to remove all applet usage in [JDK-8354695](https://bugs.openjdk.org/browse/JDK-8354695). Since this test still fails on older JDKs and is not a regression, I chose to skip the test specifically for Nimbus LAF. I suspect this is better than ProblemListing the test for Windows since the test only fails on Windows if Nimbus LAF is used.
> 
> I also removed the automated failing of the test to allow the user to see the failure message before the test closes. Test instructions are updated to align with this.

test/jdk/javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java line 72:

> 70:         checkNimbusLaf();
> 71:         PassFailJFrame.builder()
> 72:                 .title("HorizScrollers Instructions")

Title can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26165#discussion_r2203881155

From dnguyen at openjdk.org  Fri Jul 18 18:27:51 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 18 Jul 2025 18:27:51 GMT
Subject: RFR: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
In-Reply-To: <4Bvx3CSBb5gUCOCix3skCjJ-e5bmyWr9rTvSSRyRkd8=.5ebb7658-e20e-46e5-a92b-6a53d34488f6@github.com>
References: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
 <4Bvx3CSBb5gUCOCix3skCjJ-e5bmyWr9rTvSSRyRkd8=.5ebb7658-e20e-46e5-a92b-6a53d34488f6@github.com>
Message-ID: <X37wlQ8_EM_M6aX28hf3FYiLDWGdxK7NSsRjCKK9hJ8=.582c0e8b-ab2b-414e-b66d-0823cc596de3@github.com>

On Mon, 14 Jul 2025 05:32:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>> This test only fails in the automated portion on Windows with Nimbus LAF. The failure message is always that the leading cell is not aligned, but I see no obvious issues with the UI when testing myself. The test fails in older JDK versions as well. The original test relies on applet and cannot be run exactly, but this test was previously converted to remove all applet usage in [JDK-8354695](https://bugs.openjdk.org/browse/JDK-8354695). Since this test still fails on older JDKs and is not a regression, I chose to skip the test specifically for Nimbus LAF. I suspect this is better than ProblemListing the test for Windows since the test only fails on Windows if Nimbus LAF is used.
>> 
>> I also removed the automated failing of the test to allow the user to see the failure message before the test closes. Test instructions are updated to align with this.
>
> test/jdk/javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java line 72:
> 
>> 70:         checkNimbusLaf();
>> 71:         PassFailJFrame.builder()
>> 72:                 .title("HorizScrollers Instructions")
> 
> Title can be removed.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26165#discussion_r2211333217

From dnguyen at openjdk.org  Fri Jul 18 18:27:50 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 18 Jul 2025 18:27:50 GMT
Subject: RFR: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
In-Reply-To: <V2RwVfV4XBSb2-dE2uOTD9QY50ehgAh1qBjPtbWfQgg=.97774559-f939-49c8-97d8-eb026aae17b4@github.com>
References: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
 <V2RwVfV4XBSb2-dE2uOTD9QY50ehgAh1qBjPtbWfQgg=.97774559-f939-49c8-97d8-eb026aae17b4@github.com>
Message-ID: <HL7C1P-P1cPx5Wcqj8YF_NaINgr2ea6fLoFeX4vy07o=.c52c3796-b395-47d6-bdcd-09e86a0a119c@github.com>

On Tue, 8 Jul 2025 12:43:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> What exactly is the failure thrown in Nimbus L&F? JBS says `PassFailJFrame.forceFail `is called From my running it seems the failure is `"java.lang.RuntimeException: leading cell is not aligned"` It can be a genuine issue for Nimbus since it behaves ok for other L&F..

I ran into the same issue when I previously checked this. I can submit a Nimbus issue afterwards if needed. Wanted to handle the test here first.

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

PR Comment: https://git.openjdk.org/jdk/pull/26165#issuecomment-3071312180

From bchristi at openjdk.org  Fri Jul 18 18:54:40 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 18 Jul 2025 18:54:40 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
 <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>
Message-ID: <KmfMoclQekbrLs-M9jyvWcYUZK8aNgUGL5V4GY4rp10=.34979a37-2f69-4bdd-a67f-108faa178811@github.com>

On Fri, 18 Jul 2025 03:34:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I can migrate the current API of DIsposer to the something similar to CFRetainedResource as a follow up bug. The current one did not introduce the new issues, since implementation via finalize has the same bug.

Sounds good. True, the issue already existed with the finalizer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26331#issuecomment-3090377931

From bchristi at openjdk.org  Fri Jul 18 19:21:40 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 18 Jul 2025 19:21:40 GMT
Subject: RFR: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java [v4]
In-Reply-To: <VfsWAXSruKUY7P4cVRrrb-JwvMWJwzsCysEk2r3haU8=.bc40fdd5-fee6-4214-9d31-f25fed068a97@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
 <VfsWAXSruKUY7P4cVRrrb-JwvMWJwzsCysEk2r3haU8=.bc40fdd5-fee6-4214-9d31-f25fed068a97@github.com>
Message-ID: <Zb1lPYxIKDHGk8OuKONxyswj6tPfSfjcx4c0ThV8KPE=.e326202b-6887-46b6-b415-47c31e283373@github.com>

On Thu, 17 Jul 2025 21:25:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
>> 
>> I don't see a way to add a test to verify this clean up.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8362291

Marked as reviewed by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26332#pullrequestreview-3034626988

From prr at openjdk.org  Fri Jul 18 20:58:34 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 18 Jul 2025 20:58:34 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java
Message-ID: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>

Remove finalize method from CStrike.java

This one is a bit odd in that there's already a Disposer used - and in fact it involves two classes
CStrikeDisposer.java and its subclass - the nested class CStrike.GlyphInfoCache
CStrike.GlyphInfoCache is tracking all the glyph image references.

CStrikeDisposer has the full set of constructors of its superclass - FontStrikeDisposer including support
for the native context

And if supplied, CStrikeDisposer will call the native method freeNativeScalerContext(long) to free the native context
but that native method does not exist !
And there's no CStrike.GlyphInfoCache constructor which allows it to be specified

So the fix is to add that and call the disposeNativeStrikePtr method instead.

I also rejigged things a little so nativeStrikePtr could be final which is supposed to help with the thread visibility.

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

Commit messages:
 - 8210765

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

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

From prr at openjdk.org  Fri Jul 18 21:15:30 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 18 Jul 2025 21:15:30 GMT
Subject: RFR: 8362659: Remove sun.print.PrintJob2D.finalize()
Message-ID: <A190wOrjAFhdzpa-PjMdmfIhxNhtoJ_ZSAvr7vwbZvA=.091aa8b8-1471-4f31-8816-fd5eff25d2cc@github.com>

Remove sun.print.PrintJob2D.finalize() - it duplicates the super class finalize()
See the bug report for additional info.

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

Commit messages:
 - 8362659

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

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

From serb at openjdk.org  Sat Jul 19 00:17:43 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 19 Jul 2025 00:17:43 GMT
Subject: RFR: 8362659: Remove sun.print.PrintJob2D.finalize()
In-Reply-To: <A190wOrjAFhdzpa-PjMdmfIhxNhtoJ_ZSAvr7vwbZvA=.091aa8b8-1471-4f31-8816-fd5eff25d2cc@github.com>
References: <A190wOrjAFhdzpa-PjMdmfIhxNhtoJ_ZSAvr7vwbZvA=.091aa8b8-1471-4f31-8816-fd5eff25d2cc@github.com>
Message-ID: <KyoXj3JGbWoFeYrT-rmjsAgVfG0QOBARqpsm4rZUU88=.d697dffe-2159-4def-80fd-26dc85f0c076@github.com>

On Fri, 18 Jul 2025 21:09:51 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove sun.print.PrintJob2D.finalize() - it duplicates the super class finalize()
> See the bug report for additional info.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26398#pullrequestreview-3035013204

From psadhukhan at openjdk.org  Mon Jul 21 02:21:26 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 21 Jul 2025 02:21:26 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
Message-ID: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>

Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

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

Commit messages:
 - Remove listener
 - 4938801: The popup does not go when the component is removed.

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

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

From kizune at openjdk.org  Mon Jul 21 07:17:46 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 21 Jul 2025 07:17:46 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
 <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
Message-ID: <xkdkj6nWwPPhGI3rjPEBtCNFoN24ehivMzgRaYJ5eKA=.af5576a7-4840-40aa-aaf3-96476a26d2d0@github.com>

On Tue, 15 Jul 2025 03:58:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It means exactly that, and it is also impossible to request the first character after the caret position if it is at the start of the document. For both cases getAtIndex() should work.

Ok, let's step away from the documentation and try to focus on the use case of this method. Method is supposed to expose navigation within the text component to the assistive technology devices and programs. One of such programs (not the only one) is a text narrator. These narrators are meant to be used on text components and they have special shortcuts to narrate the previous and next word or character compared to the current caret position. And if you say that at the end of the text when caret is behind the last symbol the "narrate previous word before cursor" should say "null" or just say nothing - well, i would like to know what is your logic behind it because for me it is clearly wrong. The documentation needs to be corrected as well as implementation - first of all it does not take into account bidirectional text and i think that might be a problem - but the fix here doing the right thing regarding physical meaning of this interface in the context of accessibility.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3095528873

From rgupta at openjdk.org  Mon Jul 21 07:25:56 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Mon, 21 Jul 2025 07:25:56 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v4]
In-Reply-To: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
Message-ID: <4eKAMw3rHDJT8olA-Xen1pO3CAsUNT3E64gnLBCLJjM=.ee464c63-5ba2-48c7-ab72-0d53383ead65@github.com>

> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
> 
> 
>  finally {
>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>         }
>     public static void disposeFrame() {
>         if (frame != null) {
>             frame.dispose();
>             frame = null;
>         }
>     }

Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:

  8361067: Test Refactor with review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26043/files
  - new: https://git.openjdk.org/jdk/pull/26043/files/417d94e1..ecaa0334

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

  Stats: 148 lines in 1 file changed: 68 ins; 38 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/26043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26043/head:pull/26043

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

From rgupta at openjdk.org  Mon Jul 21 07:39:59 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Mon, 21 Jul 2025 07:39:59 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v5]
In-Reply-To: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
Message-ID: <-D_WFgPNXfXpyroETEyJ2hc0e-uh78pW7iLklGhZzJ0=.76eeac45-f0a2-4900-b317-0541a6c6a0fc@github.com>

> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
> 
> 
>  finally {
>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>         }
>     public static void disposeFrame() {
>         if (frame != null) {
>             frame.dispose();
>             frame = null;
>         }
>     }

Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:

  8361067: header update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26043/files
  - new: https://git.openjdk.org/jdk/pull/26043/files/ecaa0334..a45a9bf7

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

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

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

From serb at openjdk.org  Mon Jul 21 07:46:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 21 Jul 2025 07:46:29 GMT
Subject: RFR: 8362572: Delete the usage of "sun.java2d.reftype" from the
 sun.java2d.Disposer
Message-ID: <0f2Ti8nv15nMGJXY0Bf0m-PM1JrgCxX8VND2sXxBXgE=.52d4a317-b5e6-4121-aaaa-22032ec59905@github.com>

Just a code cleanup to reduce the amount of code we need to care about, test, and support.

The class sun.java2d.Disposer can use either weak or phantom references. For many years it has used phantom references by default.

One reason why weak references were supported is because phantom references keep a strong reference to the object until the reference is added to the reference queue and cleared. This behavior changed after the fix for [JDK-8071507](https://bugs.openjdk.org/browse/JDK-8071507). Now both weak and phantom references behave the same way when it comes to clearing the reference to the object.

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

Commit messages:
 - 8362572: Delete the usage of "sun.java2d.reftype" from the sun.java2d.Disposer

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

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

From serb at openjdk.org  Mon Jul 21 07:53:41 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 21 Jul 2025 07:53:41 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <xkdkj6nWwPPhGI3rjPEBtCNFoN24ehivMzgRaYJ5eKA=.af5576a7-4840-40aa-aaf3-96476a26d2d0@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
 <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
 <xkdkj6nWwPPhGI3rjPEBtCNFoN24ehivMzgRaYJ5eKA=.af5576a7-4840-40aa-aaf3-96476a26d2d0@github.com>
Message-ID: <m4o14sJQEqanrIDvoAhJ5i3ciNgJBJCHjxRO1LqyV0g=.147370dd-d631-4c98-9ef2-a776c4f1c123@github.com>

On Mon, 21 Jul 2025 07:14:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Ok, let's step away from the documentation and try to focus on the use case of this method. Method is supposed to expose navigation within the text component to the assistive technology devices and programs. One of such programs (not the only one) is a text narrator. These narrators are meant to be used on text components and they have special shortcuts to narrate the previous and next word or character compared to the current caret position.

Those narrators should not use the AccessibleText interface blindly. Instead, they should check the specification and decide which methods to call and when. The method in question cannot return the first or last word in some scenarios, so relying on it without understanding its limitations could lead to incorrect behavior.

> The documentation needs to be corrected as well as implementation - first of all it does not take into account bidirectional text and i think that might be a problem - but the fix here doing the right thing regarding physical meaning of this interface in the context of accessibility.

The proposed solution is not backward compatible, may cause exceptions in 3p code, and does not follow the pattern used in other components that implement AccessibleText.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3095624540

From mvs at openjdk.org  Mon Jul 21 08:53:56 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 21 Jul 2025 08:53:56 GMT
Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no
 Myanmar font is found
Message-ID: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>

Hi all,

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

The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.

Testing: Tested well on all platforms using Mach5 and got full Pass.

Thanks!

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

Commit messages:
 - Backport bcad87eacbd7fbfd3254479b7e061bab34e64aec

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

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

From syan at openjdk.org  Mon Jul 21 09:35:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 09:35:54 GMT
Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no
 Myanmar font is found
In-Reply-To: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
References: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
Message-ID: <bjj0cUl6jSwyO6PGuBY1rCjCSwvM2qcqzAy_uRkJ6SA=.c6a262d0-7c7c-46ce-9033-ee39e8ed7d14@github.com>

On Mon, 21 Jul 2025 08:48:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
> 
> Testing: Tested well on all platforms using Mach5 and got full Pass.
> 
> Thanks!

Duplicated to https://github.com/openjdk/jdk/pull/25946

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

PR Comment: https://git.openjdk.org/jdk/pull/26410#issuecomment-3095915608

From syan at openjdk.org  Mon Jul 21 09:36:42 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Jul 2025 09:36:42 GMT
Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no
 Myanmar font is found
In-Reply-To: <SEhK63jiP9bR_SBG7w1UiyziIesr1Hfpe3y70-Vpg0o=.b636d1b8-8a72-4ff5-9ee6-8337d175eaec@github.com>
References: <SEhK63jiP9bR_SBG7w1UiyziIesr1Hfpe3y70-Vpg0o=.b636d1b8-8a72-4ff5-9ee6-8337d175eaec@github.com>
Message-ID: <q5R_chwU802CHtEh6WFmqsmc5IkPAeFPuW5gWlKoLK4=.760670da-7fa7-4520-9fd1-01012b763ab9@github.com>

On Tue, 24 Jun 2025 02:29:49 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
> 
> Thanks!

GHA report two jdk build configure failures, I think it's infrasture issue, unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/25946#issuecomment-3095919297

From rgupta at openjdk.org  Mon Jul 21 10:02:51 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Mon, 21 Jul 2025 10:02:51 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v2]
In-Reply-To: <Okxwz68KwRZP51syF0SSrS03wECdl6sfv7bv96zGM_4=.b1f7e5c2-1b2a-4e8c-aa81-9dec40845029@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <ikIJnDHEM6UMFCL17-1GdPUNzJaJUxKs0CdGvUjRfrQ=.95038f2b-14ec-4515-98d5-032c51c98834@github.com>
 <Okxwz68KwRZP51syF0SSrS03wECdl6sfv7bv96zGM_4=.b1f7e5c2-1b2a-4e8c-aa81-9dec40845029@github.com>
Message-ID: <OpABvwTukEFcKnob1WQ1n7MF_v4fWJqbN_ptrEsxywc=.af8e2b94-6160-4c96-90f8-cd28fb88ca81@github.com>

On Mon, 7 Jul 2025 06:31:35 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8361067: EventQueue.invokeAndWait used
>
> Fix to dispose the frame looks good but the test needs re-factoring like expand wild imports, accessing UI components on EDT, code formatting etc.
> 
> I suggest to raise a JBS issue to address these issues.

@kumarabhi006 i have refactor the test its solved yours suggestions. 
Please have a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/26043#issuecomment-3095992776

From dnguyen at openjdk.org  Mon Jul 21 16:41:24 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 21 Jul 2025 16:41:24 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <q-mVlD-xlD7DLd76C6ef7NTN38glMUicW22BuVrv4cc=.263cba70-f2de-4779-b1b2-681b8c24af99@github.com>

On Mon, 21 Jul 2025 02:16:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 947:

> 945:             public void propertyChange(PropertyChangeEvent e) {
> 946:                 String propertyName = e.getPropertyName();
> 947:                 if (propertyName == "ancestor") {

Just curious, where is the `ancestor` property added to the listener list? I have tried tracking this down to follow the logic, and I could not find it, nor can I find it under the bound properties list on javadoc.

Testing seems to be ok AFAIK but I wanted to trace the code to double-check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2219703042

From prr at openjdk.org  Mon Jul 21 16:52:54 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 16:52:54 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
Message-ID: <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>

> Remove finalize method from CStrike.java
> 
> This one is a bit odd in that there's already a Disposer used - and in fact it involves two classes
> CStrikeDisposer.java and its subclass - the nested class CStrike.GlyphInfoCache
> CStrike.GlyphInfoCache is tracking all the glyph image references.
> 
> CStrikeDisposer has the full set of constructors of its superclass - FontStrikeDisposer including support
> for the native context
> 
> And if supplied, CStrikeDisposer will call the native method freeNativeScalerContext(long) to free the native context
> but that native method does not exist !
> And there's no CStrike.GlyphInfoCache constructor which allows it to be specified
> 
> So the fix is to add that and call the disposeNativeStrikePtr method instead.
> 
> I also rejigged things a little so nativeStrikePtr could be final which is supposed to help with the thread visibility.

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

  8210765

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26397/files
  - new: https://git.openjdk.org/jdk/pull/26397/files/69d1ac65..9993f18d

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

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

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

From prr at openjdk.org  Mon Jul 21 16:52:54 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 16:52:54 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java
In-Reply-To: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
Message-ID: <ThjiA8BIbCq1vkb9-QxYwq6iL2T_mJcJyAXqOhu3tvc=.2ce3d64e-9465-47b2-a981-e67d184d6208@github.com>

On Fri, 18 Jul 2025 20:51:04 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove finalize method from CStrike.java
> 
> This one is a bit odd in that there's already a Disposer used - and in fact it involves two classes
> CStrikeDisposer.java and its subclass - the nested class CStrike.GlyphInfoCache
> CStrike.GlyphInfoCache is tracking all the glyph image references.
> 
> CStrikeDisposer has the full set of constructors of its superclass - FontStrikeDisposer including support
> for the native context
> 
> And if supplied, CStrikeDisposer will call the native method freeNativeScalerContext(long) to free the native context
> but that native method does not exist !
> And there's no CStrike.GlyphInfoCache constructor which allows it to be specified
> 
> So the fix is to add that and call the disposeNativeStrikePtr method instead.
> 
> I also rejigged things a little so nativeStrikePtr could be final which is supposed to help with the thread visibility.

Not ready yet

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

PR Comment: https://git.openjdk.org/jdk/pull/26397#issuecomment-3092571727

From aivanov at openjdk.org  Mon Jul 21 17:17:30 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 21 Jul 2025 17:17:30 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <rlOliMXeZEq3T4yg26tiDhtPe_NTOk3XOsQi7HZnCaE=.736a83ca-72b7-4ed6-a779-5b1148dc9ebc@github.com>

On Mon, 21 Jul 2025 02:16:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 962:

> 960:             ui.uninstallUI(this);
> 961:             if (oldInvoker != null) {
> 962:                 oldInvoker.removePropertyChangeListener(propListener);

This won't remove the install `propListener` because a new instance of the listener is created each time the method is called.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 56:

> 54:     static volatile Rectangle size;
> 55: 
> 56:     public static class MyThread implements Runnable {

Do you even need another thread?

The test is driven from the main thread, and you can remove the component from container on the main thread.

Perhaps, a better version of the test would remove the component when the event from the popup menu that it's now displayed is received. If the popup is hidden as the result of component removal, another event should be received. Thus, the test would depend on the events and latches instead of on the delays.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 68:

> 66:             System.out.println("Starting 3 second countdown...");
> 67:             try{
> 68:                 Thread.currentThread().sleep(3000);

Suggestion:

                Thread.sleep(3000);

`sleep` is a static method, no instance of `Thread` is needed.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 71:

> 69:             } catch (Exception e) {}
> 70:             System.out.println("Removing popup invoker from the container.");
> 71:             box.remove(invo);

This breaks Swing contract that components must be accessed via EDT only.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 92:

> 90:                     jpm.add("Three");
> 91:                 }
> 92:                 jpm.show(label, 0, 0);

The popup can be shown programmatically without mouse click: `invokeAndWait(() -> jpm.show())` after the initial `waitForIdle` and delay.

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

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3038970876
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2219765853
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2219783806
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2219767297
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2219772804
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2219786884

From aivanov at openjdk.org  Mon Jul 21 17:20:27 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 21 Jul 2025 17:20:27 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
In-Reply-To: <q-mVlD-xlD7DLd76C6ef7NTN38glMUicW22BuVrv4cc=.263cba70-f2de-4779-b1b2-681b8c24af99@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <q-mVlD-xlD7DLd76C6ef7NTN38glMUicW22BuVrv4cc=.263cba70-f2de-4779-b1b2-681b8c24af99@github.com>
Message-ID: <zDxpTmg6EGh_C66N659dRT_SyhRH6OylzGQoEwNO4HM=.da71cee0-bcf5-45ee-8582-ae83d8654244@github.com>

On Mon, 21 Jul 2025 16:35:57 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 947:
> 
>> 945:             public void propertyChange(PropertyChangeEvent e) {
>> 946:                 String propertyName = e.getPropertyName();
>> 947:                 if (propertyName == "ancestor") {
> 
> Just curious, where is the `ancestor` property added to the listener list? I have tried tracking this down to follow the logic, and I could not find it, nor can I find it under the bound properties list on javadoc.
> 
> Testing seems to be ok AFAIK but I wanted to trace the code to double-check.

The changes to the `ancestor` property are fired from `JComponent.addNotify` and `removeNotify` correspondingly:

https://github.com/openjdk/jdk/blob/9dd93c6a2c5fb4c3a9f2a063a7ab402f9292ad03/src/java.desktop/share/classes/javax/swing/JComponent.java#L4837

https://github.com/openjdk/jdk/blob/9dd93c6a2c5fb4c3a9f2a063a7ab402f9292ad03/src/java.desktop/share/classes/javax/swing/JComponent.java#L4858

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2219797877

From prr at openjdk.org  Mon Jul 21 17:21:26 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 17:21:26 GMT
Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no
 Myanmar font is found
In-Reply-To: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
References: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
Message-ID: <1UNAlJcBl6C6ZXg_VJdw4la8gTMYmyeZnnB56ZV1LDM=.90a3e166-b68e-488e-9e38-6edd922d1c9e@github.com>

On Mon, 21 Jul 2025 08:48:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
> 
> Testing: Tested well on all platforms using Mach5 and got full Pass.
> 
> Thanks!

Is this a mistake ? JDK 25 has been in RDP 2 for 2 weeks and this is not an allowed fix in RDP2
https://openjdk.org/jeps/3#rdp-2

Perhaps you meant 25u ??

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

PR Comment: https://git.openjdk.org/jdk/pull/26410#issuecomment-3097659106

From prr at openjdk.org  Mon Jul 21 17:30:29 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 17:30:29 GMT
Subject: RFR: 8362572: Delete the usage of "sun.java2d.reftype" from the
 sun.java2d.Disposer
In-Reply-To: <0f2Ti8nv15nMGJXY0Bf0m-PM1JrgCxX8VND2sXxBXgE=.52d4a317-b5e6-4121-aaaa-22032ec59905@github.com>
References: <0f2Ti8nv15nMGJXY0Bf0m-PM1JrgCxX8VND2sXxBXgE=.52d4a317-b5e6-4121-aaaa-22032ec59905@github.com>
Message-ID: <kKhw7aM5g0Eo-_BI_zR3mM7AGvXIXvmvdwgXAHtVdtM=.8c44b375-f578-4a9f-bb15-3632dd9b002f@github.com>

On Fri, 18 Jul 2025 19:07:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Just a code cleanup to reduce the amount of code we need to care about, test, and support.
> 
> The class sun.java2d.Disposer can use either weak or phantom references. For many years it has used phantom references by default.
> 
> One reason why weak references were supported is because phantom references keep a strong reference to the object until the reference is added to the reference queue and cleared. This behavior changed after the fix for [JDK-8071507](https://bugs.openjdk.org/browse/JDK-8071507). Now both weak and phantom references behave the same way when it comes to clearing the reference to the object.

Looks OK. I checked to see if any tests use this, but didn't find any.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26394#pullrequestreview-3039058858

From prr at openjdk.org  Mon Jul 21 17:37:30 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 17:37:30 GMT
Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no
 Myanmar font is found
In-Reply-To: <q5R_chwU802CHtEh6WFmqsmc5IkPAeFPuW5gWlKoLK4=.760670da-7fa7-4520-9fd1-01012b763ab9@github.com>
References: <SEhK63jiP9bR_SBG7w1UiyziIesr1Hfpe3y70-Vpg0o=.b636d1b8-8a72-4ff5-9ee6-8337d175eaec@github.com>
 <q5R_chwU802CHtEh6WFmqsmc5IkPAeFPuW5gWlKoLK4=.760670da-7fa7-4520-9fd1-01012b763ab9@github.com>
Message-ID: <DvwJsDqJPyOeM-f6u_1am5Z_39odX77IbrQuyRQNmHo=.6a7207ad-a43e-431b-9ce5-6c72e70ee3dd@github.com>

On Mon, 21 Jul 2025 09:34:27 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
>> 
>> Thanks!
>
> GHA report two jdk build configure failures, I think it's infrasture issue, unrelated to this PR.

@sendaoYan 
I saw this mentioned in a duplicate PR. Unfortunately it is now too late for this for JDK 25.
It would have been OK when submitted but that's not what counts.

But I'm curious why you proposed this back port.
It doesn't appear to be your fix and you probably should never have proposed it.

Let's just withdraw it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25946#issuecomment-3097705092

From mvs at openjdk.org  Mon Jul 21 17:40:40 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 21 Jul 2025 17:40:40 GMT
Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no
 Myanmar font is found
In-Reply-To: <1UNAlJcBl6C6ZXg_VJdw4la8gTMYmyeZnnB56ZV1LDM=.90a3e166-b68e-488e-9e38-6edd922d1c9e@github.com>
References: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
 <1UNAlJcBl6C6ZXg_VJdw4la8gTMYmyeZnnB56ZV1LDM=.90a3e166-b68e-488e-9e38-6edd922d1c9e@github.com>
Message-ID: <oop-Huyii9t6Ri0PJmPLAXeaDa-TRIEP1ypp_TUOGyE=.17a41831-4ca9-4a48-848c-bdbe48a6431a@github.com>

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

>> Hi all,
>> 
>> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
>> 
>> Testing: Tested well on all platforms using Mach5 and got full Pass.
>> 
>> Thanks!
>
> Is this a mistake ? JDK 25 has been in RDP 2 for 2 weeks and this is not an allowed fix in RDP2
> https://openjdk.org/jeps/3#rdp-2
> 
> Perhaps you meant 25u ??

Yes @prrace , I will close this and raise a new request for jdk25u. But this PR doesn't show any critical-approval required checkbox, is it intentional, or that work flow is not implemented for jdk mainline branches?.

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

PR Comment: https://git.openjdk.org/jdk/pull/26410#issuecomment-3097712478

From mvs at openjdk.org  Mon Jul 21 17:54:36 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 21 Jul 2025 17:54:36 GMT
Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no
 Myanmar font is found
In-Reply-To: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
References: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
Message-ID: <pDgS01FIwI1_1EtmfQpMDtexQ9yI4mhCp5xNQGp-EZA=.c1934ee5-34cf-4572-b245-fa9047434594@github.com>

On Mon, 21 Jul 2025 08:48:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
> 
> Testing: Tested well on all platforms using Mach5 and got full Pass.
> 
> Thanks!

Closing this and raised a new PR for 25u -> https://github.com/openjdk/jdk25u/pull/24

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

PR Comment: https://git.openjdk.org/jdk/pull/26410#issuecomment-3097830149

From mvs at openjdk.org  Mon Jul 21 17:54:37 2025
From: mvs at openjdk.org (Manukumar V S)
Date: Mon, 21 Jul 2025 17:54:37 GMT
Subject: [jdk25] Withdrawn: 8358697: TextLayout/MyanmarTextTest.java passes if
 no Myanmar font is found
In-Reply-To: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
References: <nI7I8hWUBd_IXq-dzhOv8PnYeSc1Hj8nGx0x1p9VFZ0=.503d525b-20cc-4ba5-b8b6-ddded3de70c5@github.com>
Message-ID: <-QSVc6asAdiwjx6crmXym54kP_dCLeJE6eo4n9xvUJw=.71dfd8b0-f880-4adb-8a0d-4789b13ebd26@github.com>

On Mon, 21 Jul 2025 08:48:41 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
> 
> Testing: Tested well on all platforms using Mach5 and got full Pass.
> 
> Thanks!

This pull request has been closed without being integrated.

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

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

From prr at openjdk.org  Mon Jul 21 19:54:30 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 19:54:30 GMT
Subject: Integrated: 8362659: Remove sun.print.PrintJob2D.finalize()
In-Reply-To: <A190wOrjAFhdzpa-PjMdmfIhxNhtoJ_ZSAvr7vwbZvA=.091aa8b8-1471-4f31-8816-fd5eff25d2cc@github.com>
References: <A190wOrjAFhdzpa-PjMdmfIhxNhtoJ_ZSAvr7vwbZvA=.091aa8b8-1471-4f31-8816-fd5eff25d2cc@github.com>
Message-ID: <w26BjAne0MHI61ykGsl3FBllRCdu6LMbjrX8IoVqGaY=.0c2ccc63-9050-4599-b088-82bcf4d52df7@github.com>

On Fri, 18 Jul 2025 21:09:51 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove sun.print.PrintJob2D.finalize() - it duplicates the super class finalize()
> See the bug report for additional info.

This pull request has now been integrated.

Changeset: b8da9695
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8da9695f0cc049d6a07a7382afce4d22f8b2b1c
Stats:     9 lines in 1 file changed: 0 ins; 9 del; 0 mod

8362659: Remove sun.print.PrintJob2D.finalize()

Reviewed-by: serb

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

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

From aivanov at openjdk.org  Mon Jul 21 20:17:31 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 21 Jul 2025 20:17:31 GMT
Subject: RFR: 8362572: Delete the usage of "sun.java2d.reftype" from the
 sun.java2d.Disposer
In-Reply-To: <0f2Ti8nv15nMGJXY0Bf0m-PM1JrgCxX8VND2sXxBXgE=.52d4a317-b5e6-4121-aaaa-22032ec59905@github.com>
References: <0f2Ti8nv15nMGJXY0Bf0m-PM1JrgCxX8VND2sXxBXgE=.52d4a317-b5e6-4121-aaaa-22032ec59905@github.com>
Message-ID: <lGVe25Ie5nrKyvLvWC-YVuUKQxIwAKnPd_I7nlFSiXU=.4d342908-bb0c-4e6b-99db-e54a96b653d4@github.com>

On Fri, 18 Jul 2025 19:07:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Just a code cleanup to reduce the amount of code we need to care about, test, and support.
> 
> The class sun.java2d.Disposer can use either weak or phantom references. For many years it has used phantom references by default.
> 
> One reason why weak references were supported is because phantom references keep a strong reference to the object until the reference is added to the reference queue and cleared. This behavior changed after the fix for [JDK-8071507](https://bugs.openjdk.org/browse/JDK-8071507). Now both weak and phantom references behave the same way when it comes to clearing the reference to the object.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26394#pullrequestreview-3039641594

From prr at openjdk.org  Mon Jul 21 21:03:31 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 21:03:31 GMT
Subject: Integrated: 8362291: [macOS] Remove finalize method in
 CGraphicsEnvironment.java
In-Reply-To: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
References: <HTwmhsX_5FXMhEaQEqRQae4DBf40V5XdALbz5YvrIOo=.fad218bc-4c42-427c-be47-b907d3883cf9@github.com>
Message-ID: <ivnS2jm4f6Q7dRehRmLcF6_e0fBBTy0LDuDqIAeIGzY=.51b941cc-e0ac-40dd-b58d-9752a945a1bc@github.com>

On Tue, 15 Jul 2025 20:42:15 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove a finalize() method in CGraphicsEnvironment, replacing it with Disposer.
> 
> I don't see a way to add a test to verify this clean up.

This pull request has now been integrated.

Changeset: 523993e9
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/523993e9e8edc8dc84667ee3311a708b8b5da59c
Stats:     17 lines in 3 files changed: 6 ins; 0 del; 11 mod

8362291: [macOS] Remove finalize method in CGraphicsEnvironment.java

Reviewed-by: bchristi, serb, kizune

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

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

From prr at openjdk.org  Mon Jul 21 21:05:36 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 21:05:36 GMT
Subject: Integrated: 8362557: [macOS] Remove CFont.finalize()
In-Reply-To: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>
References: <UfBvuAUCTUPleLbd4H83FFbAsGOY4LEvwMnihJUFJpo=.0360d653-5331-4393-924f-cd7a2db35f22@github.com>
Message-ID: <IY7nNx19QmAZhxfaegwm3In-uOM1bvP8ucWCke_Uj7Q=.eb99b146-967a-4992-a3ba-84b5900ac231@github.com>

On Thu, 17 Jul 2025 21:30:10 GMT, Phil Race <prr at openjdk.org> wrote:

> Replace CFont.finalize() with a disposer.

This pull request has now been integrated.

Changeset: 3acdba38
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3acdba38cec95ced2b2dd6a183c9b5d22dcc4b26
Stats:     14 lines in 1 file changed: 9 ins; 1 del; 4 mod

8362557: [macOS] Remove CFont.finalize()

Reviewed-by: serb, psadhukhan, kizune

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

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

From prr at openjdk.org  Mon Jul 21 21:06:34 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Jul 2025 21:06:34 GMT
Subject: Integrated: 8362452: [macOS] Remove CPrinterJob.finalize()
In-Reply-To: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
References: <LAbhPb52zGTWLwrO4uq8kdJX88T2xXniNIQm_O4h-SA=.a2cd6a09-319b-4067-b3d5-968e306a8874@github.com>
Message-ID: <wDgl7hdac-KklskYXV_ivn5mTkCZK3HYjqyJRb92aAk=.0a90607b-fca0-4d97-9463-a2ef423aaa26@github.com>

On Wed, 16 Jul 2025 20:47:23 GMT, Phil Race <prr at openjdk.org> wrote:

> Replace finalization with 2D Disposer

This pull request has now been integrated.

Changeset: eceb3bbc
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eceb3bbc80aae5d99155218f755725041edbb8ab
Stats:     51 lines in 2 files changed: 30 ins; 0 del; 21 mod

8362452: [macOS] Remove CPrinterJob.finalize()

Reviewed-by: serb, psadhukhan, kizune

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

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

From serb at openjdk.org  Tue Jul 22 00:41:33 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 22 Jul 2025 00:41:33 GMT
Subject: Integrated: 8362572: Delete the usage of "sun.java2d.reftype" from the
 sun.java2d.Disposer
In-Reply-To: <0f2Ti8nv15nMGJXY0Bf0m-PM1JrgCxX8VND2sXxBXgE=.52d4a317-b5e6-4121-aaaa-22032ec59905@github.com>
References: <0f2Ti8nv15nMGJXY0Bf0m-PM1JrgCxX8VND2sXxBXgE=.52d4a317-b5e6-4121-aaaa-22032ec59905@github.com>
Message-ID: <o0tJ26k3YZ118P6U6f2EbjtbwHPd7XwDptjgWJhkr6U=.ed188377-696a-4bb6-90b4-014323f0485b@github.com>

On Fri, 18 Jul 2025 19:07:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Just a code cleanup to reduce the amount of code we need to care about, test, and support.
> 
> The class sun.java2d.Disposer can use either weak or phantom references. For many years it has used phantom references by default.
> 
> One reason why weak references were supported is because phantom references keep a strong reference to the object until the reference is added to the reference queue and cleared. This behavior changed after the fix for [JDK-8071507](https://bugs.openjdk.org/browse/JDK-8071507). Now both weak and phantom references behave the same way when it comes to clearing the reference to the object.

This pull request has now been integrated.

Changeset: 7d7d308d
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d7d308d9ab6f06ebdab0f5967a5bfc007d4217f
Stats:     27 lines in 1 file changed: 2 ins; 21 del; 4 mod

8362572: Delete the usage of "sun.java2d.reftype" from the sun.java2d.Disposer

Reviewed-by: prr, aivanov

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

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

From syan at openjdk.org  Tue Jul 22 00:53:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 00:53:29 GMT
Subject: [jdk25] RFR: 8358697: TextLayout/MyanmarTextTest.java passes if no
 Myanmar font is found
In-Reply-To: <SEhK63jiP9bR_SBG7w1UiyziIesr1Hfpe3y70-Vpg0o=.b636d1b8-8a72-4ff5-9ee6-8337d175eaec@github.com>
References: <SEhK63jiP9bR_SBG7w1UiyziIesr1Hfpe3y70-Vpg0o=.b636d1b8-8a72-4ff5-9ee6-8337d175eaec@github.com>
Message-ID: <kvTk4fqcrxRPyjzbYmjNzr5cnTq-evPbDA5ynrHBa6U=.8982059a-994a-4548-88ab-740c0bb16d53@github.com>

On Tue, 24 Jun 2025 02:29:49 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
> 
> Thanks!

Duplicated to https://github.com/openjdk/jdk25u/pull/24

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

PR Comment: https://git.openjdk.org/jdk/pull/25946#issuecomment-3100170369

From syan at openjdk.org  Tue Jul 22 00:53:30 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 22 Jul 2025 00:53:30 GMT
Subject: [jdk25] Withdrawn: 8358697: TextLayout/MyanmarTextTest.java passes if
 no Myanmar font is found
In-Reply-To: <SEhK63jiP9bR_SBG7w1UiyziIesr1Hfpe3y70-Vpg0o=.b636d1b8-8a72-4ff5-9ee6-8337d175eaec@github.com>
References: <SEhK63jiP9bR_SBG7w1UiyziIesr1Hfpe3y70-Vpg0o=.b636d1b8-8a72-4ff5-9ee6-8337d175eaec@github.com>
Message-ID: <9leG8bvg30I2Cj4ctII2tiiHI5rxH56a7PMTDvK05LA=.b0fa0e00-9b37-49e5-9c2e-776922760adf@github.com>

On Tue, 24 Jun 2025 02:29:49 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bcad87ea](https://github.com/openjdk/jdk/commit/bcad87eacbd7fbfd3254479b7e061bab34e64aec) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Manukumar V S on 24 Jun 2025 and was reviewed by Alexey Ivanov.
> 
> Thanks!

This pull request has been closed without being integrated.

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

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

From abaya at openjdk.org  Tue Jul 22 02:02:33 2025
From: abaya at openjdk.org (Anass Baya)
Date: Tue, 22 Jul 2025 02:02:33 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux
In-Reply-To: <6rkJv8BuGgrA2L7AQ-gXfvqcRqADHLgZaq9PC3aGZ8w=.64ff2902-b225-4c08-840c-6277b64b40c2@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
 <6rkJv8BuGgrA2L7AQ-gXfvqcRqADHLgZaq9PC3aGZ8w=.64ff2902-b225-4c08-840c-6277b64b40c2@github.com>
Message-ID: <K2BawMIlal_NAOujVkVAABKKJHvUfCNqd5DzE0QIzxI=.9fc33d67-c24e-467f-bcc4-9a4b561e089c@github.com>

On Tue, 15 Jul 2025 19:52:15 GMT, Alisen Chung <achung at openjdk.org> wrote:

> > The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
> 
> What's causing the recursive re-entry? Is the bug in the code path in linux when calling getFocusableWindowState?

Hello @alisenchung, @mrserb,

In the test, we override getFocusableWindowState() to call removeNotify(). During the execution of removeNotify(), getFocusableWindowState() is called again as you see in the call stack, which leads to an infinite recursive loop and eventually results in a StackOverflowError


getFocusableWindowState()
  ??? removeNotify()
         ...
        ??? isFocusableWindow()
               ...
              ??? getFocusableWindowState() ? loop


At first, I thought this was a bug in the test and submitted a fix (as shown in the PR). However, since @mrserb  mentioned that the JDK should be able to handle this scenario on Linux, I?m continuing to investigate the issue further.

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

PR Comment: https://git.openjdk.org/jdk/pull/26298#issuecomment-3100428466

From psadhukhan at openjdk.org  Tue Jul 22 03:08:24 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Jul 2025 03:08:24 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v2]
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <pBsNSAntmqgINTh6PEZWl11VEOyvs0cNecL2IT2iEyM=.8b146013-79e0-48e9-9581-6aa2aac829bf@github.com>

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove correct instance of PropertyListener

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26407/files
  - new: https://git.openjdk.org/jdk/pull/26407/files/35e0dbad..ad6bcc4b

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

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

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

From psadhukhan at openjdk.org  Tue Jul 22 03:08:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Jul 2025 03:08:25 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v2]
In-Reply-To: <zDxpTmg6EGh_C66N659dRT_SyhRH6OylzGQoEwNO4HM=.da71cee0-bcf5-45ee-8582-ae83d8654244@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <q-mVlD-xlD7DLd76C6ef7NTN38glMUicW22BuVrv4cc=.263cba70-f2de-4779-b1b2-681b8c24af99@github.com>
 <zDxpTmg6EGh_C66N659dRT_SyhRH6OylzGQoEwNO4HM=.da71cee0-bcf5-45ee-8582-ae83d8654244@github.com>
Message-ID: <u7RvBgSv_43R6aT9PsPxPjJaNH-v-6ryCXPrDxzA73c=.2c0af4dd-76a2-462f-ba25-2ed62d14c4e5@github.com>

On Mon, 21 Jul 2025 17:17:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 947:
>> 
>>> 945:             public void propertyChange(PropertyChangeEvent e) {
>>> 946:                 String propertyName = e.getPropertyName();
>>> 947:                 if (propertyName == "ancestor") {
>> 
>> Just curious, where is the `ancestor` property added to the listener list? I have tried tracking this down to follow the logic, and I could not find it, nor can I find it under the bound properties list on javadoc.
>> 
>> Testing seems to be ok AFAIK but I wanted to trace the code to double-check.
>
> The changes to the `ancestor` property are fired from `JComponent.addNotify` and `removeNotify` correspondingly:
> 
> https://github.com/openjdk/jdk/blob/9dd93c6a2c5fb4c3a9f2a063a7ab402f9292ad03/src/java.desktop/share/classes/javax/swing/JComponent.java#L4837
> 
> https://github.com/openjdk/jdk/blob/9dd93c6a2c5fb4c3a9f2a063a7ab402f9292ad03/src/java.desktop/share/classes/javax/swing/JComponent.java#L4858

Guess  I already mentioned in the description

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2220906005

From prr at openjdk.org  Tue Jul 22 05:08:26 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 05:08:26 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
 <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>
Message-ID: <4EF17yjfvyOmHJFAuVDzC2qG3UuJEyOGO4ZJRhKQz9A=.6c301779-593e-4866-a566-b3b95d4fd214@github.com>

On Fri, 18 Jul 2025 03:34:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Synchronized methods might be OK without, but the following methods are not synchronized, and access cfDictionaryPtr:
> 
> Unfortunately this is actually true, in awt we even have a special class [CFRetainedResource](https://github.com/openjdk/jdk/blob/04c0b130f09c093797895cc928fe020d7e584cb9/src/java.desktop/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java#L36) which maintains a locks around the native pointer and prevents its usage after de-allocation(intentional or via finalize). It was implemented as part of JDK-8164143.
> 
> I can migrate the current API of DIsposer to the something similar to CFRetainedResource as a follow up bug. The current one did not introduce the new issues, since implementation via finalize has the same bug.

What does that mean ?

CFRetainedResource is extended by a lot of classes and it is hard to figure out how correctly it is used.
I would take a big step back and look before extending what it does.
And it also uses finalize which is why I looked and found what a mess it is.

> I would recommend adding a `reachabiltyFence()` to `Disposer.addRecord()`, as @mrserb [suggests](https://github.com/openjdk/jdk/pull/26331/files#r2208586134).
> 
> Unexpected unreachability is a subtle problem with GC-assisted APIs - finalizers, `Cleaner`, and even direct use of `References` & `ReferenceQueues`. In particular, the VM can decide than object is unreachable even when a method on that object is still running.
> 
> For this reason, our standard recommendation is that any instance method that accesses the cleanable state (in this case, `cfDictionaryPtr`) should be enclosed with a `try{...}finally{ reachabilityFence(); }` block.
> 
> Synchronized methods _might_ be OK without, but the following methods are not synchronized, and access `cfDictionaryPtr`:
> 
> * `getHitForPoint()`
> * `getPartBounds()`
> * `getScrollBarOffsetChange()`
> * `sync()`

I do not see any scenario in which this is needed.
I will evaluate if we need to  file a bug to use reachabiltyFence in the Disposer creation since that is a one-time contained thing but  I have no reason to suppose it is needed in this class.

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

PR Comment: https://git.openjdk.org/jdk/pull/26331#issuecomment-3100996792
PR Comment: https://git.openjdk.org/jdk/pull/26331#issuecomment-3101010453

From duke at openjdk.org  Tue Jul 22 07:06:00 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Tue, 22 Jul 2025 07:06:00 GMT
Subject: RFR: 8251928: [macos] the printer DPI always be 72,
 cause some content lost when print out [v2]
In-Reply-To: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
References: <rR0Z3tgI9pY3Bh5XTqUr2Q_wf4kspUitnygW5CgxHE4=.1f2586f7-b715-457f-88ed-247155d6fb90@github.com>
Message-ID: <2cMXK6hNodtaqZV0bC8hOkzvLrQTYLMgca8nqHjroNg=.5f683b33-d24d-4170-8037-e169c3ecf194@github.com>

> The fix for the https://bugs.openjdk.org/browse/JDK-8251928.
> 
> **Description**.
> This PR contains changes to be able to print with DPI higher than 72 on macOS, set default CPrinterJob DPI is 300 like in the PSPrinterJob.
> 
> As described in the macOS drawing guide, the following steps are required to draw with high DPI (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html#//apple_ref/doc/uid/TP40003290-CH204-BCICIJAJ):
> 1. Convert the user-space point, size, or rectangle value to device space coordinates;
> 2. Normalize the value in device space so that it is aligned to the appropriate pixel boundary;
> 3. Convert the normalized value back to user space;
> 4. Draw your content using the adjusted value. 
>     
> The 1-st step is now implemented in the CPrinterJob, a Graphics provided to the print method adjusted to a printer's DPI.
> The 2-nd step is a drawing process in the java code (without changes).
> The 3-rd step is now implemented in the PrinterView.m, the drawing scaled back to the 72 DPI.
> The 4-th step is a drawing process in the native code (without changes).
> 
> **Tests**.
> I run all tests from javax.print package and there is no any regression.
> New test covers macOS and Linux only because we know its default DPI - 300.

GennadiyKrivoshein 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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into macOS_printing_DPI
 - [macos] the printer DPI always be 72

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25489/files
  - new: https://git.openjdk.org/jdk/pull/25489/files/05568097..3d61732d

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

  Stats: 145880 lines in 3016 files changed: 87538 ins; 36017 del; 22325 mod
  Patch: https://git.openjdk.org/jdk/pull/25489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25489/head:pull/25489

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

From psadhukhan at openjdk.org  Tue Jul 22 08:28:51 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Jul 2025 08:28:51 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v3]
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26407/files
  - new: https://git.openjdk.org/jdk/pull/26407/files/ad6bcc4b..0037a482

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

  Stats: 65 lines in 1 file changed: 14 ins; 47 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26407/head:pull/26407

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

From psadhukhan at openjdk.org  Tue Jul 22 08:28:52 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Jul 2025 08:28:52 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v3]
In-Reply-To: <rlOliMXeZEq3T4yg26tiDhtPe_NTOk3XOsQi7HZnCaE=.736a83ca-72b7-4ed6-a779-5b1148dc9ebc@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <rlOliMXeZEq3T4yg26tiDhtPe_NTOk3XOsQi7HZnCaE=.736a83ca-72b7-4ed6-a779-5b1148dc9ebc@github.com>
Message-ID: <9wrykNQsIEXVYbsVbdQokG9flKbAnp0F16pkw72tuA4=.147e6b8b-a4e9-4494-9f10-b34e2037e2ee@github.com>

On Mon, 21 Jul 2025 17:02:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update
>
> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 962:
> 
>> 960:             ui.uninstallUI(this);
>> 961:             if (oldInvoker != null) {
>> 962:                 oldInvoker.removePropertyChangeListener(propListener);
> 
> This won't remove the install `propListener` because a new instance of the listener is created each time the method is called.

Fixed..

> test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 71:
> 
>> 69:             } catch (Exception e) {}
>> 70:             System.out.println("Removing popup invoker from the container.");
>> 71:             box.remove(invo);
> 
> This breaks Swing contract that components must be accessed via EDT only.

Test updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2221680253
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2221681291

From duke at openjdk.org  Tue Jul 22 14:18:48 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 22 Jul 2025 14:18:48 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v7]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <iSZxE7i4mGgXVvC5KeIvGHqz6yBUq9-kam6V27CdEVw=.73e2e44c-0649-408c-8f08-d75d7120c94a@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare 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 nine additional commits since the last revision:

 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Merge branch 'openjdk:master' into jdk-8158801
 - Changes protected fields to static
 - Problem list files for Mac OS only
 - Removes passed tests from problem list
 - Changes Frame width to 300, uses protected constants for all base tests frame sizes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/35cf3e5b..0b53b89e

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

  Stats: 4003 lines in 156 files changed: 3149 ins; 375 del; 479 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Tue Jul 22 14:18:48 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 22 Jul 2025 14:18:48 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v4]
In-Reply-To: <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <UZWiDXCGexlW-5b0SAk2LQZXbJqYXGl6EDb1IvvrY40=.6f87f62c-e7da-4a9a-b932-ed1924ee5ff1@github.com>
 <39xl5aQY2HuUC0LgmN9bx6nnlU0GXtPuxfLppsJMZQo=.8de93834-80fd-49ba-a832-7de7a8c388d8@github.com>
 <zOh3ewAMO5XBWuwW3Tk_uptq2iLz-bQZiYGeaV1J8ao=.47ef5f53-a49e-416a-8085-7e3641e966cb@github.com>
Message-ID: <7Ow8DonxoXiWGsffkEBMmTbFqhEqUjXyH7q9R4-qOHQ=.bb07af8d-4197-49dc-96c4-aeaba34898ef@github.com>

On Fri, 18 Jul 2025 04:00:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
>> 
>> I have tested with undecorated frames, but the test continues to fail. The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
>> 
>> I will set the frames (The background undecorated frame, and the heavyweight component frames) on center as you have suggested.
>
>> In Windows machines, the click lands on the reduce control of the window, and this causes the windows to be iconified and the test fails.
> 
> WHich test in particular? or is it all tests have this behavior?
> 
>> The test needs to click on the middle of the Windows title bar (Outside of the controls) to pass.
> 
> I tried JMenuBarOverlapping.java but I dont see any click on title bar..The cursor in on top-left of "Test Menu" menu..
> If clicking on the title bar is needed to make it gain focus, probably you can try with calling `frame.requestFocus` and use `CountDownLatch `with timeout to wait till FOCUS_GAINED event is received and release the latch in `focusGained()` and then start the test

@prsadhuk after applying your suggested change, I can see that it has fixed the issue for most of the tests but still the following tests didn't pass on Windows compared with the original fix of changing frame width :

java/awt/Mixing/AWT_Mixing/JProgressBarInGlassPaneOverlapping.java
java/awt/Mixing/AWT_Mixing/JScrollBarInGlassPaneOverlapping.java
java/awt/Mixing/AWT_Mixing/JSliderInGlassPaneOverlapping.java
java/awt/Mixing/AWT_Mixing/JTextAreaInGlassPaneOverlapping.java
java/awt/Mixing/AWT_Mixing/JTextFieldInGlassPaneOverlapping.java
java/awt/Mixing/AWT_Mixing/JToggleButtonInGlassPaneOverlapping.java
java/awt/Mixing/AWT_Mixing/OpaqueOverlapping.java

I will check why these tests had failed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3102899641

From duke at openjdk.org  Tue Jul 22 14:42:07 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 22 Jul 2025 14:42:07 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v8]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <nqCBY-1kkGhSlRtTEu6JK9GqRBJsjRoIwL9U-gTAa74=.45292d89-1a58-442c-8bff-1c0b4c751fbd@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Merge branch 'openjdk:master' into jdk-8158801

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/0b53b89e..655487d0

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

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

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

From kcr at openjdk.org  Tue Jul 22 15:00:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 15:00:36 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
Message-ID: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>

This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.

The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.


src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
src/jdk.compiler/share/data/symbols/symbols
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list


I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into 8359760-rm-jsobject
 - Bump copyright year
 - Merge remote-tracking branch 'upstream/master' into 8359760-rm-jsobject
 - 8359760: Remove the jdk.jsobject module

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

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

From kcr at openjdk.org  Tue Jul 22 15:00:36 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 15:00:36 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <Jy76wevmXN0kbyz2G-gSH2SrK9dfwZadFX2je3roZA0=.79941b87-398d-4812-910e-163520606089@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

@RogerRiggs @AlanBateman Can you review this PR to remove the `jdk.jsobject` module, which was deprecated for removal by PR #20555 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3103204720

From alanb at openjdk.org  Tue Jul 22 15:09:25 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Jul 2025 15:09:25 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

I did a quick scan and the updates to the conf, the removal, and the test changes look okay. Happy to review the CSR when you have it ready.

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3103254196

From rriggs at openjdk.org  Tue Jul 22 15:18:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 15:18:52 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:

> 303: jdk.jshell.spi
> 304: jdk.jshell.tool
> 305: module:jdk.jsobject

There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
Can it be removed? Unless it causes a test failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2222878346

From duke at openjdk.org  Tue Jul 22 15:39:54 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 22 Jul 2025 15:39:54 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v9]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <cfrkoBuErcWvhXG_rMP6EdadDte8uoUtA2ZktafGseA=.0256c3a3-40f0-41cc-b656-024d1c0241d9@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare has updated the pull request incrementally with four additional commits since the last revision:

 - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
   
   This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
 - Revert "Removes passed tests from problem list"
   
   This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
 - Revert "Problem list files for Mac OS only"
   
   This reverts commit f68973cc2e4b68a18b7c6ec04aebd75bf0c1899a.
 - Revert "Changes protected fields to static"
   
   This reverts commit fa864b2fb7f68c2b33726482c78425e63bf8a396.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/655487d0..f041ed29

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

  Stats: 42 lines in 7 files changed: 30 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Tue Jul 22 15:48:43 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 22 Jul 2025 15:48:43 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v10]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <xWmROL5f1WAqzDBCuNleu5eCEUtqdTiGkE2VcJUJP5w=.16407991-01c0-47af-9102-5034a976672b@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare has updated the pull request incrementally with two additional commits since the last revision:

 - Removes some tests from problem list
 - Uses request frame focus instead of Robot clicks to request frame focus

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/f041ed29..f99d5599

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=08-09

  Stats: 47 lines in 7 files changed: 11 ins; 21 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Tue Jul 22 15:50:19 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 22 Jul 2025 15:50:19 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v9]
In-Reply-To: <cfrkoBuErcWvhXG_rMP6EdadDte8uoUtA2ZktafGseA=.0256c3a3-40f0-41cc-b656-024d1c0241d9@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <cfrkoBuErcWvhXG_rMP6EdadDte8uoUtA2ZktafGseA=.0256c3a3-40f0-41cc-b656-024d1c0241d9@github.com>
Message-ID: <xbMJOLqwlODJZTDQFgNE0ZAWOov63SJuwMcAHmPEU3A=.401b59e2-ef5c-4c96-af49-fb8e0c088d97@github.com>

On Tue, 22 Jul 2025 15:39:54 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
>    
>    This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
>  - Revert "Removes passed tests from problem list"
>    
>    This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
>  - Revert "Problem list files for Mac OS only"
>    
>    This reverts commit f68973cc2e4b68a18b7c6ec04aebd75bf0c1899a.
>  - Revert "Changes protected fields to static"
>    
>    This reverts commit fa864b2fb7f68c2b33726482c78425e63bf8a396.

Reverted previous initial changes with frame width set to 300 pixels.

Used request focus for frames and most of the test passed. 

Updated copyright years.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3103531107

From duke at openjdk.org  Tue Jul 22 16:35:27 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Tue, 22 Jul 2025 16:35:27 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v11]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <tE3II29C7hJ3A6OhHm9uSXWse5qVuXpiaXISHThwPZI=.34edf028-c520-476b-99df-e4541c78bc55@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Restores copyright year for tests not updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/f99d5599..fdd052fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=09-10

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

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

From prr at openjdk.org  Tue Jul 22 18:23:02 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 18:23:02 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v15]
In-Reply-To: <hKjP2gOKt4E954rI5oZPeirIpDUu2SHa2P8AYVIF1JU=.6ab9ce2f-4647-4cfd-a9da-02f03c281978@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <hKjP2gOKt4E954rI5oZPeirIpDUu2SHa2P8AYVIF1JU=.6ab9ce2f-4647-4cfd-a9da-02f03c281978@github.com>
Message-ID: <Q9wS9tAiECDzKOS5AAdLn6GOvoo92HUraVgII7ZDzmU=.7fd84386-7654-4419-bac2-f62cc099dc37@github.com>

On Sun, 13 Jul 2025 09:12:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Document NPE behaviour and update test and add class-level statement
>  - Document NPE behaviour and update test and add class-level statement

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:

> 66:  * no exceptions will be thrown but the image will be 'effectively' null,
> 67:  * as it will have no dimensions and never be drawn, and
> 68:  * getImageLoadStatus() will report ERRORED.

ERRORED should be a link - I presume to MediaTracker.ERRORED

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 215:

> 213:     /**
> 214:      * Creates an ImageIcon from the image.
> 215:      * Passing {@code null} Image will result in {@code NullPointerException}.

"Passing" -> "Passing a"

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 228:

> 226:      * If the image has a "comment" property that is a string,
> 227:      * then the string is used as the description of this icon.
> 228:      * Passing {@code null} Image will result in {@code NullPointerException}.

"Passing" -> "Passing a"

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 388:

> 386:     public void setImage(Image image) {
> 387:         this.image = image;
> 388:         if (image == null) {

Umm. We had decided (in the end) to document the NPE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2223374128
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2223376459
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2223376633
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2223418097

From prr at openjdk.org  Tue Jul 22 18:23:03 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 18:23:03 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v14]
In-Reply-To: <fu9Y19OZi8xW0cL2P4BmPmG0pYzDRAAZfZsg7RMb1cU=.bc2d4ab5-0f14-4b31-88f8-68c160d2c32a@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <Vpufu5rbsuJ8iHO6d09uYWxF3fhtvtljfm8cvDg_rww=.5a70a2d0-ad42-4ecb-8c09-2c3f8890227b@github.com>
 <fu9Y19OZi8xW0cL2P4BmPmG0pYzDRAAZfZsg7RMb1cU=.bc2d4ab5-0f14-4b31-88f8-68c160d2c32a@github.com>
Message-ID: <ewAmpGPBp6ZAAOuN_4WAYt1I677GVgF2y6pO_jpCovg=.e109add7-4814-46d7-a9eb-b9d5c6364283@github.com>

On Tue, 8 Jul 2025 12:56:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   constructor test removal
>
> test/jdk/javax/swing/ImageIcon/ImageIconNullImageTest.java line 34:
> 
>> 32: import javax.swing.ImageIcon;
>> 33: 
>> 34: public class ImageIconNullImageTest {
> 
> I guess we're going to update the test later with follow-up fixes?
> 
> However, I suggest dropping `ImageIcon-` from the test class name ? the test is in `ImageIcon` folder, therefore it tests `ImageIcon`.

I don't have a problem with the test name .. either way  .. but if you drop it from the test name you should also drop it from all the method names.

This test is really long. I thought I sent you a more succinct way of doing it.
Here's what I wrote - tests only the null cases but its a start.

import java.awt.Image;
import java.io.File;
import java.net.URL;
import javax.swing.ImageIcon;

public class ImageIconTest {

    static enum ArgType { FILE, URL, BYTEARRAY, IMAGE };

    public static void main(String[] args) throws Exception {

        String s = null;
        byte[] b = null;
        Image i = null;
        URL u = null;
        
        for (ArgType a : ArgType.values()) {
            boolean expected = true;
            boolean passed = false;
            try {
                switch (a) {
                   case FILE :
                       expected = false;
                       new ImageIcon((String)null);
                       passed = true; // no exception expected for this case
                       break;
                   case URL :
                       new ImageIcon((URL)null);
                       break;
                   case BYTEARRAY :
                       byte[] bytes = null;
                       new ImageIcon(bytes);
                       break;
                   case IMAGE :
                       new ImageIcon((Image)null);
                       break;
                }
            } catch (NullPointerException e) {
               if (expected) passed = true;
            }
            if (expected && !passed) {
               System.err.println("Did not receive expected exception for : " + a);
               throw new RuntimeException("Test failed");
            }
            if (!expected && !passed) {
               System.err.println("Received unexpected exception for : " + a);
               throw new RuntimeException("Test failed");
            }
        }

        // test setter
        try {
            ImageIcon ii = new ImageIcon();
            ii.setImage((Image)null);
            throw new RuntimeException("No NPE");
        } catch (NullPointerException e) {
            // expected
        }
    }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2223383983

From kcr at openjdk.org  Tue Jul 22 18:39:53 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 18:39:53 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <3jmBibdv4ZqVjUF9FI7KNvJ2H3siKn2H-WivoPRaWXw=.f399ac98-c29d-46a2-9c39-7ec5cd691623@github.com>
Message-ID: <4YzUhJJKnuwc6-nZe7m-PHszEBfhGhb4s2YRW-DmTc0=.27cf04dd-69f6-492e-ae6f-5a001740c877@github.com>

On Tue, 22 Jul 2025 15:06:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I did a quick scan and the updates to the conf, the removal, and the test changes look okay. Happy to review the CSR when you have it ready.

Thanks. The CSR is now ready to review: https://bugs.openjdk.org/browse/JDK-8362628

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3104282605

From kcr at openjdk.org  Tue Jul 22 18:47:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 18:47:00 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
Message-ID: <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>

On Tue, 22 Jul 2025 15:13:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:
> 
>> 303: jdk.jshell.spi
>> 304: jdk.jshell.tool
>> 305: module:jdk.jsobject
> 
> There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
> Can it be removed? Unless it causes a test failure.

I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).

https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56


    private static final String externalDocs =
        "https://docs.oracle.com/en/java/javase/17/docs/api";


I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223507650

From rriggs at openjdk.org  Tue Jul 22 18:51:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 18:51:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
Message-ID: <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>

On Tue, 22 Jul 2025 18:44:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testModules/jdk/element-list line 305:
>> 
>>> 303: jdk.jshell.spi
>>> 304: jdk.jshell.tool
>>> 305: module:jdk.jsobject
>> 
>> There is a similar pair in test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list.
>> Can it be removed? Unless it causes a test failure.
>
> I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).
> 
> https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56
> 
> 
>     private static final String externalDocs =
>         "https://docs.oracle.com/en/java/javase/17/docs/api";
> 
> 
> I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?

I ran the test and then removed those lines and the test still passed.
I'd remove them to avoiding leaving a (little) mess behind.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223524163

From prr at openjdk.org  Tue Jul 22 19:04:55 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 19:04:55 GMT
Subject: RFR: 8361524: [XWayland] possible JavaFX interop hang
In-Reply-To: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
References: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
Message-ID: <4XY5Gsk7sq_K20QuJIuhKuEHtX_wwhVHqDSVm7Tm734=.b21cfbe7-a6aa-433b-a3ee-7b3e7a71ed70@github.com>

On Mon, 7 Jul 2025 21:41:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Callbacks in the `src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c` file normally have the following pattern:
> 
> 
> helper->isDone = TRUE;
> callbackEnd();
> // return;
> 
> 
> Failing to call `callbackEnd()` could result in a hang if another GTK loop is running (e.g., JavaFX see https://github.com/openjdk/jdk/pull/22131#issue-2660482472).
> 
> This fix corrects this flaw.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26172#pullrequestreview-3044477125

From prr at openjdk.org  Tue Jul 22 19:10:05 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 19:10:05 GMT
Subject: RFR: 8362898: Remove finalize() methods from javax.imagio TIFF
 classes.
Message-ID: <X-lrqNQSpo2EIYSMxAMUTqROPoXmKRqxfCV8OKTztQ8=.fe557cf2-0a8c-435d-bd94-fef78ccddac2@github.com>

Remove finalize from TIFF ImageIO implementatation classes.

Following copied from the bug description 
The TIFF image (de)compressors can make use of a JPEG reader / writer
Like all ImageIO readers and writers, once done, the owner should call their dispose() method.
This is currently done with finalize() to ensure it isn't missed.

This can be migrated to a Disposer.

However, the most common case is that it is the ImageIO built-in JPEGImageReader and JPEGImageWriter
that is located and that already implements a Disposer. So there is no need to add a Disposer for that.
We only need to add it if we find some other reader/writer.

With enough work, it might be possible for the TIFF compressor/decompressor classes to work out when
they are really done and avoid a Disposer at all. But it could also be that they instead need to discard
them when a specific task is done and then obtain a new one.
That would be much more overhead than just adding a Disposer for the rare case and regardless
of what is done in the TIFF code, the built in JPEG classes will install their own Disposer so I don't
think I want to pursue that route.

I also noticed that TIFFBaseJPEGCompressor.java can replace the current writer if it doesn't satisfy a need.
In that case it just nulls it out and doesn't call dispose() and of course finalize() will then refer to the replacement.
So I added direct calls to dispose() in such a case. That was definitely necessary with the finalize() code
but the Disposer would have taken care of it anyway, so it isn't strictly needed with the new code but
it is still good to do it early if you can.

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

Commit messages:
 - 8362898
 - 8362898

Changes: https://git.openjdk.org/jdk/pull/26416/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26416&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8362898
  Stats: 44 lines in 3 files changed: 31 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26416/head:pull/26416

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

From kcr at openjdk.org  Tue Jul 22 19:43:55 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 19:43:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module
In-Reply-To: <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
Message-ID: <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>

On Tue, 22 Jul 2025 18:48:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I wondered about that, and originally was going to remove it, but then noticed that the test in question parses the JDK 17 API docs (which does have the `jdk.jsobject` module).
>> 
>> https://github.com/openjdk/jdk/blob/e70c702d6f864b494dc7df3eea4f1a317a3bc981/test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java#L55-56
>> 
>> 
>>     private static final String externalDocs =
>>         "https://docs.oracle.com/en/java/javase/17/docs/api";
>> 
>> 
>> I suspect that the test will run just fine if I remove it. I don't mind either way. What would you recommend?
>
> I ran the test and then removed those lines and the test still passed.
> I'd remove them to avoiding leaving a (little) mess behind.

As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2223678605

From kcr at openjdk.org  Tue Jul 22 19:53:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 22 Jul 2025 19:53:39 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

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

  Remove jdk.jsobject from one more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26393/files
  - new: https://git.openjdk.org/jdk/pull/26393/files/e70c702d..2858cd3e

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

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

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

From rriggs at openjdk.org  Tue Jul 22 19:55:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Jul 2025 19:55:55 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <-GRJ-l0avR6jYVCgrpu6s1wDdNzxpfrpxDFb__T-X8M=.c8d7e16c-cc62-4fd2-a6b0-7d8f2add3871@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

look good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3044678258

From prr at openjdk.org  Tue Jul 22 20:00:03 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 20:00:03 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
 <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>
Message-ID: <UYMhJrKa9J3SO5DSvZkRHlgvQ3-awe31twRd7kieqKo=.4e2307c2-d64f-496c-8bf2-adef670946bc@github.com>

On Fri, 18 Jul 2025 03:34:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JRSUIControl.java
>
>>Synchronized methods might be OK without, but the following methods are not synchronized, and access cfDictionaryPtr:
> 
> Unfortunately this is actually true, in awt we even have a special class [CFRetainedResource](https://github.com/openjdk/jdk/blob/04c0b130f09c093797895cc928fe020d7e584cb9/src/java.desktop/macosx/classes/sun/lwawt/macosx/CFRetainedResource.java#L36) which maintains a locks around the native pointer and prevents its usage after de-allocation(intentional or via finalize). It was implemented as part of JDK-8164143.
> 
> I can migrate the current API of DIsposer to the something similar to CFRetainedResource as a follow up bug. The current one did not introduce the new issues, since implementation via finalize has the same bug.

> > I would recommend adding a `reachabiltyFence()` to `Disposer.addRecord()`, as @mrserb [suggests](https://github.com/openjdk/jdk/pull/26331/files#r2208586134).
...

> I will evaluate if we need to file a bug to use reachabiltyFence in the Disposer creation since that is a one-time contained thing but I have no reason to suppose it is needed in this class.

I have at least filed the [enhancement] bug on this : https://bugs.openjdk.org/browse/JDK-8363886

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

PR Comment: https://git.openjdk.org/jdk/pull/26331#issuecomment-3104650964

From iris at openjdk.org  Tue Jul 22 20:15:56 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 22 Jul 2025 20:15:56 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <riykbCOmZWw8xZyznbpjn_f9Zk1tppnltpXdS3jwfvo=.bdb4180d-d2c1-4bee-85fb-e6df77bfd5d6@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3044742971

From achung at openjdk.org  Tue Jul 22 21:45:00 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 22 Jul 2025 21:45:00 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v3]
In-Reply-To: <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>
Message-ID: <E3KxLkDv_b-fXsZwDjil2_46kWtdR8NMRETbMF_IvRs=.c44946f0-4cd6-41d1-9090-b2cd0ad7c0d3@github.com>

On Tue, 22 Jul 2025 08:28:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Test is failing for me on macOS with error: Execution failed: `main' threw exception: java.lang.RuntimeException: poup is visible after component is removed

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

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3044958742

From vistall.valeriy at gmail.com  Fri Jul 11 18:02:51 2025
From: vistall.valeriy at gmail.com (Valery Semenchuk)
Date: Fri, 11 Jul 2025 22:02:51 +0400
Subject: 8360136: Support setting 'Figure Styles' while creating AWT Font
Message-ID: <CACbmvyWrDbk=V=zShh7deo-87DGTZE+DZupUkUvG7vNMc-8abA@mail.gmail.com>

Good evening.

I've made PR https://github.com/openjdk/jdk/pull/26144 which is fix issue
https://bugs.openjdk.org/browse/JDK-8360136

(I'm author of this issue too)

Main idea - it's an add option to control pnum/tnum features.

Added impl to JNI & Panama.

I think in the future, need to rewrite code which is in C++ - and move
features control to Java (it's not part of this PR, that's why I've not
added it) - make native code more flexible.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250711/745674b7/attachment.htm>

From anthony.goubard at gmail.com  Tue Jul 22 20:36:06 2025
From: anthony.goubard at gmail.com (Anthony Goubard)
Date: Tue, 22 Jul 2025 22:36:06 +0200
Subject: Applets are not dead (JEP 504)
Message-ID: <CANsEkGvDZCcPPR1-PEghAc5XFzaOAxvUnq4um5G9ykwirv=x2A@mail.gmail.com>

Hello,

Since the mailing-list is one of the places to provide feedback, I wanted
provide feedback about JEP 504 <https://openjdk.org/jeps/504>: Remove the
Applet API

Even if the applet plug-in for browsers is not used anymore, there are
other ways applets are used.

I have developed plug-ins for IntelliJ IDEA (& similar JetBrains IDE),
Eclipse and NetBeans to be able to run applets embedded in the IDE.
The plug-ins have reached more than 50,000 downloads since 2021.
All my software (more than 20 Swing applications) are also applets. They
are also available as standalone but as applet, people can run them
embedded in their IDE or in the file manager that I wrote that also
supports running applets.

You also have products like CheerpJ and TeaVM that make (or could make)
possible to run applets embedded in a browser that supports
WASM/WebAssembly.
See the recent top comment in
https://www.reddit.com/r/java/comments/1kxchwf/cheerpj_41_java_in_the_browser_now_supporting/

Also searching for "path:*.java JApplet" results in 14,500 results in
GitHub.

I can understand that you want to get rid of old code that you think is
never used (like AppletInitializer) but I think it's not the case for the
classes Applet, AppletContext, AppletStub and JApplet.

Best regards,
Anthony Goubard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250722/051fc8de/attachment.htm>

From abhishek.cx.kumar at oracle.com  Mon Jul  7 07:04:21 2025
From: abhishek.cx.kumar at oracle.com (Abhishek Kumar)
Date: Mon, 07 Jul 2025 07:04:21 -0000
Subject: [External] : Re: Windows Magnifier does not work with my Swing
 applications
In-Reply-To: <CAA9v-_PuV+u_Yd-hEVfZ5rLk94=Yzd1yMADUEuoGTrGTmDyKrw@mail.gmail.com>
References: <CAA9v-_NR0j1aKJ-KaaN+JwH_GQay7214Q=fcFrUquurLDoLzpg@mail.gmail.com>
 <b90b84d8-64cb-47dd-acdf-98be34075c5a@oracle.com>
 <CAA9v-_PVYjQ1hB_+r85WqVUy0jfiGH8z03G6PKucDa9CRtWyEg@mail.gmail.com>
 <CAA9v-_PN0WuYYUDSfKKPKuHQ0jCsB2++s-9TcDQ5BeYDRR2zkg@mail.gmail.com>
 <CAA9v-_OKzT-gG3O3U4vEc2fneLdKNPWY2Kd=hu-8FUva3ZWqsw@mail.gmail.com>
 <d46c58f5-a25b-4b07-8d36-66885ac314ad@oracle.com>
 <CAA9v-_OG67a8ovoVP-LYJXQorn1+A9gq+6t5ye6QAyps+xrgkw@mail.gmail.com>
 <SJ2PR10MB7059510B85F8249E1AD58E91CFFD2@SJ2PR10MB7059.namprd10.prod.outlook.com>
 <CAA9v-_OGuk9UAP2xN5pi+TaZXM55patErtyW38jHX5frWG2NbQ@mail.gmail.com>
 <CAA9v-_NBzWGLCm9L7bmysHWMiuBamt_hRMNMqcYZAEe_=i2ycQ@mail.gmail.com>
 <SJ2PR10MB7059FC939F6FAC7F96C6835BCF90A@SJ2PR10MB7059.namprd10.prod.outlook.com>
 <CAA9v-_PuV+u_Yd-hEVfZ5rLk94=Yzd1yMADUEuoGTrGTmDyKrw@mail.gmail.com>
Message-ID: <IA3PR10MB8757CF0028014132C60F5EDACF4FA@IA3PR10MB8757.namprd10.prod.outlook.com>

Hello David,

I looked into the issue and tried to extend the support for Windows Magnifier for Swing application but the solution didn?t work out. I have captured my analysis in JBS for reference.

It looks like this needs further experimentation but, I can?t commit any timeline for now.

Thank you for your patience.

Regards,
Abhishek

From: David Alayachew <davidalayachew at gmail.com>
Date: Thursday, 15 May 2025 at 2:15?PM
To: Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Cc: Philip Race <philip.race at oracle.com>, Ajit Ghaisas <ajit.ghaisas at oracle.com>, client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Windows Magnifier does not work with my Swing applications

Understood. Ty vm.

On Thu, May 15, 2025, 1:19?AM Abhishek Kumar <abhishek.cx.kumar at oracle.com<mailto:abhishek.cx.kumar at oracle.com>> wrote:
Hello David,

I didn?t get enough time to investigate it further due to other priority work. But I will try to look into this issue ASAP.

Regards,
Abhishek

From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Date: Thursday, 15 May 2025 at 8:32?AM
To: Abhishek Kumar <abhishek.cx.kumar at oracle.com<mailto:abhishek.cx.kumar at oracle.com>>
Cc: Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>>, Ajit Ghaisas <ajit.ghaisas at oracle.com<mailto:ajit.ghaisas at oracle.com>>, client-libs-dev at openjdk.org<mailto:client-libs-dev at openjdk.org> <client-libs-dev at openjdk.org<mailto:client-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Windows Magnifier does not work with my Swing applications
Hey, any updates on this? I understand if not, but accessibility in Swing is important to me, even more so for the abovementioned reasons.

On Tue, Feb 11, 2025 at 5:52?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:

And thank you.

On Tue, Feb 11, 2025, 12:50?AM Abhishek Kumar <abhishek.cx.kumar at oracle.com<mailto:abhishek.cx.kumar at oracle.com>> wrote:
Hello David,

Yeah, I will evaluate if existing JDK implementation can be extended to work with Windows Magnifier. I didn?t get enough time to look into this issue due to other issues but this is on my to-do list. I will update my findings on JBS after my analysis.

Thank you for your patience.

Regards,
Abhishek

From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Date: Tuesday, 11 February 2025 at 4:39?AM
To: Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>>
Cc: Abhishek Kumar <abhishek.cx.kumar at oracle.com<mailto:abhishek.cx.kumar at oracle.com>>, client-libs-dev at openjdk.org<mailto:client-libs-dev at openjdk.org> <client-libs-dev at openjdk.org<mailto:client-libs-dev at openjdk.org>>
Subject: [External] : Re: Windows Magnifier does not work with my Swing applications

Ok, ty vm. Hey Abhishek, any updates?

On Mon, Feb 10, 2025, 5:50?PM Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:
I think I asked Abhishek to take a look.

-phil.
On 2/10/25 2:41 PM, David Alayachew wrote:

Poke.

Any new info?

On Fri, Jan 17, 2025, 8:05?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:

Hello Phil,

Did you get any more info about this issue?

On Tue, Dec 17, 2024, 11:58?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Thanks Phil.

Yeah, I am A-OK as long as this something that is looked into and the JBS Bug Report is updated with the findings. If this isn't too bad, this would be a solid inclusion. But if it's not worth the effort, I just want the JBS to be updated, and then I can put that as an answer for my StackOverflow post.

Thanks again for taking a look into this.

On Tue, Dec 17, 2024 at 11:56?AM Philip Race <philip.race at oracle.com<mailto:philip.race at oracle.com>> wrote:
Perhaps .. if it is an easy fix but I do not know the specifics and the evaluator of that bug wrote
"the magnifier cannot receive PropertyChangeEvents from Swing. This is a limitation in the Window magnifier.
The Windows magnifier could be modified by Microsoft to receive such events but the work would need to be done by Microsoft."

then went on to add that other magnifiers do work ..

I also don't know how tied in this would be to implementing support for the Windows Accessibility API.

Swing apps today use something called JavaAccessBridge and there are screen readers out there that support it.

It would be good to have another look at this specific issue, but I can't make any promises.

-phil.
On 12/15/24 1:04 PM, David Alayachew wrote:
Hello Client Libs Dev Team,

My eyesite has started to deteriorate significantly, so I have been using the built-in Accessibility tool called Windows (Screen) Magnifier (available since Windows XP at least). It zooms in and out of the screen by pressing the Windows Key and (+) or (-).

This works great because, as I type stuff, the magnifier will follow my text, so that I don't have to keep manually moving the magnifier whenever what I type inevitably ends up off-screen (off-view?).

This feature works great for basically every other application I have, except my Swing apps. I make a lot of Swing apps, and I use a bunch too. And this Magnifier feature that follows text does not work for any of the ones I have tried.

This feature does work on basically every other application I have. To name a few.

* Notepad++
* WordPad
* Firefox
* Git Bash

Here is a Bug Report referring to this problem.

https://bugs.openjdk.org/browse/JDK-5079680

The resolution was listed as "Future Project". Any chance that the future can be now?

I know that Swing is largely in maintenance mode, but if this were to get added, practically ALL Swing apps would receive a significant boost in accessibility. I think that's worth making some significant changes for.

Finally, here is a StackOverflow post I made discussing the same subject.

https://stackoverflow.com/questions/79281778<https://urldefense.com/v3/__https:/stackoverflow.com/questions/79281778__;!!ACWV5N9M2RV99hQ!Ly4-UF3NKnfHKegv0u1A73-bJexJCRENPe2tHIfIZbS-UVOiAyGFuQ5ftsZLZ3nYii9HnobMtSSE1q01jU3NB22v20jnRIk$>

Thank you for your time.
David Alayachew


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250707/ceac45e2/attachment-0001.htm>

From prr at openjdk.org  Tue Jul 22 21:49:07 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 21:49:07 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer
Message-ID: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>

As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().

PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.

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

Commit messages:
 - 8363889

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

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

From philip.race at oracle.com  Tue Jul 22 21:59:09 2025
From: philip.race at oracle.com (Philip Race)
Date: Tue, 22 Jul 2025 14:59:09 -0700
Subject: Applets are not dead (JEP 504)
In-Reply-To: <CANsEkGvDZCcPPR1-PEghAc5XFzaOAxvUnq4um5G9ykwirv=x2A@mail.gmail.com>
References: <CANsEkGvDZCcPPR1-PEghAc5XFzaOAxvUnq4um5G9ykwirv=x2A@mail.gmail.com>
Message-ID: <b25484e5-195d-44ad-9e66-495eb3e349b6@oracle.com>

Thanks for the feedback.

Since the JEP lays out the reasons for removing the API I won't repeat 
them here.

Anyone needing something like the applet API has been given 8 years of 
notice to migrate.
9 years by the time JDK 26 ships and there'll be many years of JDK 
support from multiple vendors for releases prior to that.

And as an API Applet is dated.
If I were to want to be able to use Java in a browser via WASM, or 
anything else,
I wouldn't re-use the applet API to do it.

-phil.


On 7/22/25 1:36 PM, Anthony Goubard wrote:
> Hello,
>
> Since the mailing-list is one of the places to provide feedback, I 
> wanted provide feedback about JEP 504 <https://openjdk.org/jeps/504>: 
> Remove the Applet API
>
> Even if the applet plug-in for browsers is not used anymore, there are 
> other ways applets are used.
>
> I have developed plug-ins for IntelliJ IDEA (& similar JetBrains IDE), 
> Eclipse and NetBeans to be able to run applets embedded in the IDE.
> The plug-ins have reached more than 50,000 downloads since 2021.
> All my software (more than 20 Swing applications) are also applets. 
> They are also available as standalone but as applet, people can run 
> them embedded in their IDE or in the file manager that I wrote that 
> also supports running applets.
>
> You also have products like CheerpJ and TeaVM that make (or could 
> make) possible to run applets embedded in a browser that supports 
> WASM/WebAssembly.
> See the recent top comment in 
> https://www.reddit.com/r/java/comments/1kxchwf/cheerpj_41_java_in_the_browser_now_supporting/ 
>
>
> Also searching for "path:*.java JApplet" results in 14,500 results in 
> GitHub.
>
> I can understand that you want to get rid of old code that you think 
> is never used (like AppletInitializer) but I think it's not the case 
> for the classes Applet, AppletContext, AppletStub and JApplet.
>
> Best regards,
> Anthony Goubard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250722/c4cd7593/attachment.htm>

From prr at openjdk.org  Tue Jul 22 22:10:37 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 22:10:37 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v2]
In-Reply-To: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
Message-ID: <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>

> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
> 
> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.

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

  8363889

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26432/files
  - new: https://git.openjdk.org/jdk/pull/26432/files/5d0b6737..45a5aa7c

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

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

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

From prr at openjdk.org  Tue Jul 22 22:23:26 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Jul 2025 22:23:26 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v25]
In-Reply-To: <U69ZO4AurDU0gnQ1BmBOWwhaGRtC1iVoGrtvnl_Hx2Y=.b5b54f18-4c0e-4bea-970c-f337ce8bfb3c@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <U69ZO4AurDU0gnQ1BmBOWwhaGRtC1iVoGrtvnl_Hx2Y=.b5b54f18-4c0e-4bea-970c-f337ce8bfb3c@github.com>
Message-ID: <VWn55dB-EXw53W2wdj8vW19oMX8zdVmdS7-hozBZaCI=.fc6c3bf8-4b80-4a6b-8e4d-62becbc82bfb@github.com>

On Wed, 16 Jul 2025 23:15:37 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update robot specification

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/java/awt/Robot.java line 140:

> 138: 
> 139:     private static int stepDelay = DEFAULT_STEP_DELAY;
> 140:     private static int stepLength = DEFAULT_STEP_LENGTH;

These should not be static. They apply to THIS robot instance, not all of them.

src/java.desktop/share/classes/java/awt/Robot.java line 948:

> 946:             throw new IllegalArgumentException("Step-length must be greater than zero");
> 947:         }
> 948:         Robot.stepLength = stepLength;

Not a static

src/java.desktop/share/classes/java/awt/Robot.java line 977:

> 975:             throw new IllegalArgumentException("Step delay must be between 0 and 60,000");
> 976:         }
> 977:         Robot.stepDelay = stepDelay;

Not a static

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

PR Review: https://git.openjdk.org/jdk/pull/22044#pullrequestreview-3045031189
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2223932815
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2223934691
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2223934886

From psadhukhan at openjdk.org  Wed Jul 23 03:27:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Jul 2025 03:27:00 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v16]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <5OPjgb_WeI-KIFKjiMp3lnwx_aJUvXMAtoiWZ4FfOBw=.2fdb76e7-a06e-4c54-a342-f64a4d841605@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove code change..Fix javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/dbf7edb0..765e0dfc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=14-15

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

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

From psadhukhan at openjdk.org  Wed Jul 23 03:27:01 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Jul 2025 03:27:01 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v15]
In-Reply-To: <Q9wS9tAiECDzKOS5AAdLn6GOvoo92HUraVgII7ZDzmU=.7fd84386-7654-4419-bac2-f62cc099dc37@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <hKjP2gOKt4E954rI5oZPeirIpDUu2SHa2P8AYVIF1JU=.6ab9ce2f-4647-4cfd-a9da-02f03c281978@github.com>
 <Q9wS9tAiECDzKOS5AAdLn6GOvoo92HUraVgII7ZDzmU=.7fd84386-7654-4419-bac2-f62cc099dc37@github.com>
Message-ID: <rwhOGU-tNVzkz4C4ensHbGN56Pwu4OWZBDAxQsMIzCY=.cd42336e-29ed-4217-8a0e-1ce8fcfa1c95@github.com>

On Tue, 22 Jul 2025 18:07:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Document NPE behaviour and update test and add class-level statement
>>  - Document NPE behaviour and update test and add class-level statement
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 388:
> 
>> 386:     public void setImage(Image image) {
>> 387:         this.image = image;
>> 388:         if (image == null) {
> 
> Umm. We had decided (in the end) to document the NPE.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2224239516

From psadhukhan at openjdk.org  Wed Jul 23 04:02:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Jul 2025 04:02:10 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v17]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <PETCgKle8l9fgg8EHf1z13yN4qTnaZKVsWLt1UxQ9k0=.f0f27610-477a-46b3-8672-5127cca1efdf@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:

 - Test update
 - Test update
 - Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/765e0dfc..0b8b0425

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=15-16

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

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

From psadhukhan at openjdk.org  Wed Jul 23 04:02:10 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Jul 2025 04:02:10 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v16]
In-Reply-To: <5OPjgb_WeI-KIFKjiMp3lnwx_aJUvXMAtoiWZ4FfOBw=.2fdb76e7-a06e-4c54-a342-f64a4d841605@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <5OPjgb_WeI-KIFKjiMp3lnwx_aJUvXMAtoiWZ4FfOBw=.2fdb76e7-a06e-4c54-a342-f64a4d841605@github.com>
Message-ID: <W8spbpTAnz0rs3-0NtptEfBmehv_yypk_NPZ0YiC61I=.5bf83cb8-5b52-429e-a9b0-a270b4749983@github.com>

On Wed, 23 Jul 2025 03:27:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove code change..Fix javadoc

Test updated

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

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3105584396

From psadhukhan at openjdk.org  Wed Jul 23 04:02:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Jul 2025 04:02:11 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v15]
In-Reply-To: <Q9wS9tAiECDzKOS5AAdLn6GOvoo92HUraVgII7ZDzmU=.7fd84386-7654-4419-bac2-f62cc099dc37@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <hKjP2gOKt4E954rI5oZPeirIpDUu2SHa2P8AYVIF1JU=.6ab9ce2f-4647-4cfd-a9da-02f03c281978@github.com>
 <Q9wS9tAiECDzKOS5AAdLn6GOvoo92HUraVgII7ZDzmU=.7fd84386-7654-4419-bac2-f62cc099dc37@github.com>
Message-ID: <wIvP2mvJ2PSqEpBa1gtvQjn-cWNhhltoYz3I0NzPQE0=.ec9bd393-90a4-499e-b058-461c3f025f76@github.com>

On Tue, 22 Jul 2025 17:52:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Document NPE behaviour and update test and add class-level statement
>>  - Document NPE behaviour and update test and add class-level statement
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:
> 
>> 66:  * no exceptions will be thrown but the image will be 'effectively' null,
>> 67:  * as it will have no dimensions and never be drawn, and
>> 68:  * getImageLoadStatus() will report ERRORED.
> 
> ERRORED should be a link - I presume to MediaTracker.ERRORED

Fixed

> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 228:
> 
>> 226:      * If the image has a "comment" property that is a string,
>> 227:      * then the string is used as the description of this icon.
>> 228:      * Passing {@code null} Image will result in {@code NullPointerException}.
> 
> "Passing" -> "Passing a"

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2224275974
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2224276278

From psadhukhan at openjdk.org  Wed Jul 23 04:02:11 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Jul 2025 04:02:11 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v15]
In-Reply-To: <rwhOGU-tNVzkz4C4ensHbGN56Pwu4OWZBDAxQsMIzCY=.cd42336e-29ed-4217-8a0e-1ce8fcfa1c95@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <hKjP2gOKt4E954rI5oZPeirIpDUu2SHa2P8AYVIF1JU=.6ab9ce2f-4647-4cfd-a9da-02f03c281978@github.com>
 <Q9wS9tAiECDzKOS5AAdLn6GOvoo92HUraVgII7ZDzmU=.7fd84386-7654-4419-bac2-f62cc099dc37@github.com>
 <rwhOGU-tNVzkz4C4ensHbGN56Pwu4OWZBDAxQsMIzCY=.cd42336e-29ed-4217-8a0e-1ce8fcfa1c95@github.com>
Message-ID: <AKXWN3vRWh8lhq8EeMEp0ljnkpC5XAyXlCjpjato6xs=.6f9839e3-3857-4fef-ab14-922fa339fbdb@github.com>

On Wed, 23 Jul 2025 03:20:57 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 388:
>> 
>>> 386:     public void setImage(Image image) {
>>> 387:         this.image = image;
>>> 388:         if (image == null) {
>> 
>> Umm. We had decided (in the end) to document the NPE.
>
> fixed

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2224277117

From alanb at openjdk.org  Wed Jul 23 05:57:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 05:57:57 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
Message-ID: <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>

On Tue, 22 Jul 2025 19:41:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I ran the test and then removed those lines and the test still passed.
>> I'd remove them to avoiding leaving a (little) mess behind.
>
> As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.

@hns Would it be possible to confirm that it's okay to remove this from the doclet tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2224453194

From alanb at openjdk.org  Wed Jul 23 05:57:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Jul 2025 05:57:56 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <fbETTwthRh0Si0UEVuXz19SyNsot077gwkVtOJKTnm4=.2c286921-0f84-487b-8133-4d4b3e667963@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26393#pullrequestreview-3045747196

From psadhukhan at openjdk.org  Wed Jul 23 08:43:33 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Jul 2025 08:43:33 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v18]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unneeded vars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/0b8b0425..507e8a40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=16-17

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

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

From mbaesken at openjdk.org  Wed Jul 23 13:55:45 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Jul 2025 13:55:45 GMT
Subject: RFR: 8363676: [GCC static analyzer] missing return value check of
 malloc in OGLContext_SetTransform
Message-ID: <NGuc7jn_Rduk6kikLMxo9eHanlG3LE6MFr-6MGSSz14=.1b650db7-0889-49d1-9198-01ada7ab5ce8@github.com>

When using the GCC static analyzer (-fanalyzer) the following issue is reported :
`src/java.desktop/share/native/common/java2d/opengl/OGLContext.c:487:9: warning: use of possibly-NULL '*oglc.xformMatrix' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]`

Seems we miss a NULL check of the return value of malloc (at most other places in the coding we do it).

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

Commit messages:
 - JDK-8363676

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

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

From hannesw at openjdk.org  Wed Jul 23 14:35:59 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 23 Jul 2025 14:35:59 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
Message-ID: <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>

On Wed, 23 Jul 2025 05:55:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> As expected, the above test passes fine if I remove the jsobject entries from `test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list`. I'll go ahead and remove them, since it seems like good cleanup.
>
> @hns Would it be possible to confirm that it's okay to remove this from the doclet tests?

The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225804491

From duke at openjdk.org  Wed Jul 23 14:47:41 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 23 Jul 2025 14:47:41 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v12]
In-Reply-To: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
Message-ID: <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>

> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
> 
> This fix changes the width of base frames which allows most of tests to pass.

Khalid Boulanouare 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 21 additional commits since the last revision:

 - Removes not needed component frace ancestor.
 - Problem unlists passed tests
 - Uses frame requestFocus instead of robot clicks for focus
 - Removes extra Robot waitForIdle
 - Merge branch 'openjdk:master' into jdk-8158801
 - Restores copyright year for tests not updated
 - Removes some tests from problem list
 - Uses request frame focus instead of Robot clicks to request frame focus
 - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
   
   This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
 - Revert "Removes passed tests from problem list"
   
   This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
 - ... and 11 more: https://git.openjdk.org/jdk/compare/381047de...b558508f

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25971/files
  - new: https://git.openjdk.org/jdk/pull/25971/files/fdd052fc..b558508f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25971&range=10-11

  Stats: 3103 lines in 92 files changed: 1679 ins; 902 del; 522 mod
  Patch: https://git.openjdk.org/jdk/pull/25971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25971/head:pull/25971

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

From duke at openjdk.org  Wed Jul 23 14:52:55 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Wed, 23 Jul 2025 14:52:55 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v12]
In-Reply-To: <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
Message-ID: <kYqiiK-SOcczjemamoAvdY3pbtjB4GLjdpZhZhIJiKQ=.9598d3cb-7d0c-455a-bd64-783dd98c6ca7@github.com>

On Wed, 23 Jul 2025 14:47:41 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare 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 21 additional commits since the last revision:
> 
>  - Removes not needed component frace ancestor.
>  - Problem unlists passed tests
>  - Uses frame requestFocus instead of robot clicks for focus
>  - Removes extra Robot waitForIdle
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Restores copyright year for tests not updated
>  - Removes some tests from problem list
>  - Uses request frame focus instead of Robot clicks to request frame focus
>  - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
>    
>    This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
>  - Revert "Removes passed tests from problem list"
>    
>    This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/1b51461f...b558508f

With the current changes we are back to the same fix as defined by commit f68973cc2e4b68a18b7c6ec04aebd75bf0c1899a.

Currently, only the following tests failed:

java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java
java/awt/Mixing/AWT_Mixing/JInternalFrameMoveOverlapping.java
java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java
java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java
java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java
java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java
java/awt/Mixing/AWT_Mixing/OpaqueOverlappingChoice.java

For each of the tests above, I create PR which relies on the current PR. I will bring all fixes to this PR and update other PRs that its fix has moved here, and close it, all when possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3108982577

From hannesw at openjdk.org  Wed Jul 23 15:25:01 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 23 Jul 2025 15:25:01 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
 <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
Message-ID: <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>

On Wed, 23 Jul 2025 14:33:34 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> @hns Would it be possible to confirm that it's okay to remove this from the doclet tests?
>
> The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.

Maybe my previous comment was a bit unclear. Both options are okay, leaving the entries and removing them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225940174

From kcr at openjdk.org  Wed Jul 23 15:39:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Jul 2025 15:39:58 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <39cYXy3ksJP1mbYdnC_Tz5VAJSUVx7Op43gM0Df7r7I=.77868781-e7cd-426b-b860-7bf9f7a1892b@github.com>
 <2u-KIKGxk64j-qEqoZBDCRLfmcgLVgUWpmdawQrv-Uk=.8327b9aa-d48f-4eaa-8360-4c31f9a1eba6@github.com>
 <-bXcQWNopjhUxwibF0de2l9Uc_8jZBX_qdAbY-9g3XQ=.7d704400-ac43-4486-8914-4efc735a474d@github.com>
 <kS1L5BXHrQhg2Ear1fgxGJoRFAF5_cm_mybVY2iuksQ=.e20c4f19-328a-4448-9fa0-3d53067f14d2@github.com>
 <3u6pXBfNO_0Jv6ncXqPzfEwAlMYACUs8n4hBCzVJySA=.c767eace-8e78-4449-af6a-056751167982@github.com>
 <Xqh-MwvNHBO0bwlzZHe46WiJqTzGbsiid9pZort3sG4=.fa2dc115-11b4-4036-99f6-4be73fd5adf4@github.com>
 <-6pe3kOD8As2nIe-g3ca7UPXoKKpaVBYmpDCW4VdE_o=.d530e02e-6516-4655-ac5b-a4eafa006cd8@github.com>
Message-ID: <49XysSSYVTzmKjja4l23jCkIz_gab8_qXX7eSxb2IsE=.1f07ea64-3a1b-49c6-9ef6-5b06e9616ad3@github.com>

On Wed, 23 Jul 2025 15:22:04 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> The list is used as list of external linkable modules/packages for the `-linkoffline` option. Since the list is for JDK 17 the entry could be left in the list, but as the test doesn't try to link to the module removing it doesn't make any difference.
>
> Maybe my previous comment was a bit unclear. Both options are okay, leaving the entries and removing them.

Thanks. In that case, I'll stick with the current state of the PR which removes them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26393#discussion_r2225986752

From duke at openjdk.org  Wed Jul 23 15:42:59 2025
From: duke at openjdk.org (duke)
Date: Wed, 23 Jul 2025 15:42:59 GMT
Subject: RFR: 8359760: Remove the jdk.jsobject module [v2]
In-Reply-To: <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
 <m7OmhcC5MJM7zFl3VxU0X-9tshW6Y9muegXlo-lHUcQ=.f7cf56fe-799b-4f64-8370-9bf5248e093e@github.com>
Message-ID: <lZThqhW_oV4kZT0z239m-ztL7l-fENyyolVs3dcnqn0=.80495d5f-2e75-48ea-bc2c-d7030a16d685@github.com>

On Tue, 22 Jul 2025 19:53:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
>> 
>> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
>> 
>> 
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
>> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
>> src/jdk.compiler/share/data/symbols/symbols
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
>> 
>> 
>> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove jdk.jsobject from one more test

@kevinrushforth 
Your change (at version 2858cd3e61b51f213db3265beec30d1afedf1906) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26393#issuecomment-3109170206

From kcr at openjdk.org  Wed Jul 23 15:50:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 23 Jul 2025 15:50:05 GMT
Subject: Integrated: 8359760: Remove the jdk.jsobject module
In-Reply-To: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
References: <nT8V-hnOcSbjb57ERzbFtnGxbLg_Ph43mmVWcuE4mko=.76cb6087-7df2-408a-a6e4-8edaae204516@github.com>
Message-ID: <hx0zS7djImUSZHj8604N2mlfoMh0ecey7l8pmtfy7jQ=.c470ccd7-6b43-48fe-9478-4469b75c62a0@github.com>

On Fri, 18 Jul 2025 16:58:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the terminally-deprecated `jdk.jsobject` module from the JDK. This module is now shipped with JavaFX, and has been since JavaFX 24.
> 
> The following files still reference `jdk.jsobject` (or the `netscape.javascript` package). They are not modified because these files reflect the state of earlier releases, which do have the `jdk.jsobject` module.
> 
> 
> src/jdk.compiler/share/data/symbols/jdk.jsobject-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-A.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-C.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-E.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-G.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-M.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.jsobject-O.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-8.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-9.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-B.sym.txt
> src/jdk.compiler/share/data/symbols/jdk.scripting.nashorn-F.sym.txt
> src/jdk.compiler/share/data/symbols/symbols
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-10.txt
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/releases/element-list-9.txt
> 
> 
> I have run tier1, tier2, and tier3 tests, as well as local tests with JavaFX WebView.

This pull request has now been integrated.

Changeset: 594c080b
Author:    Kevin Rushforth <kcr at openjdk.org>
Committer: Iris Clark <iris at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/594c080b2bde81a48ecccda85ac765218fc93856
Stats:     362 lines in 12 files changed: 0 ins; 358 del; 4 mod

8359760: Remove the jdk.jsobject module

Reviewed-by: rriggs, iris, alanb

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

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

From achung at openjdk.org  Wed Jul 23 18:35:52 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 23 Jul 2025 18:35:52 GMT
Subject: RFR: 8361192: Test
 java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java fails on all platforms
In-Reply-To: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
References: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
Message-ID: <8k856oS3qRazicSftpO9nTNByFqubpdHsV-FSo3gO_E=.80d9cb5b-b176-4082-953b-f9f46aa100fd@github.com>

On Mon, 7 Jul 2025 17:43:39 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Changes heavyweight color to white, for the test to pass.

Test is passing with the change, LGTM

Please update copyright years

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

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26167#pullrequestreview-3048565207
PR Comment: https://git.openjdk.org/jdk/pull/26167#issuecomment-3109686243

From achung at openjdk.org  Wed Jul 23 19:16:18 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 23 Jul 2025 19:16:18 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v26]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <qIXtdwoE92RIVk99JaQhjWOiFmeq9omI-wSYA67g95s=.a92dd45e-84da-42a5-beb1-da75ee7c33f1@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

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

  remove static from step delay/length fields

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/0496e20e..ead01714

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=24-25

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

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

From aivanov at openjdk.org  Wed Jul 23 19:46:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 23 Jul 2025 19:46:58 GMT
Subject: RFR: 8360070: AccessibleText.getBeforeIndex returns null for last
 character [v3]
In-Reply-To: <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
References: <EjmeC51-Cmv_jnZTc8CpXZMmo7oRK9Q3lyUzFb2SA0A=.b786e0d6-ab2c-4b02-8195-60ca1dbbdc4e@github.com>
 <qqUj0USio1y1Prho9PJDbwptCKmHR8xLrb1pOkIL_mE=.0826e0eb-da39-4fc6-9b11-a00bfa593409@github.com>
 <DvqimcI1C1KFqOfQnqEEHha71Gz4dvBir9Z4dGog_DI=.9a4cf5ee-4660-4862-98d3-db347ef11fd9@github.com>
 <8ymAQj9RhVlP38vUd5CZJqGxu4PAimnMsuUbvBeSSgQ=.1df4ea54-b393-4c41-b15a-e1c1dea97310@github.com>
Message-ID: <F8CziAxjVlLg2zT47gEiUjcEvjIO4hK4sSuT7rrI9IU=.e9e6a6af-2a65-4886-b64d-68488e0a1568@github.com>

On Tue, 15 Jul 2025 03:58:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I'd expect to see 9 as the return value of getBeforeIndex for the index of 10. This would make the table symmetrical.
> 
> Why do you expect that? The spec states that the index should be "an index within the text." That index is also used in other methods, such as getCharacterBounds(), etc. If we fixed it only for text at the end, it would make the behavior even less symmetric, since for a negative value, the model will always throw an exception.

I think the specification for the index parameter ? *?an index within the text?* ? is vague, it's open to interpretation.

We should make it specific. For example, is 0 within the text? It's not within, it's right before.

The same goes for the index of 10 in my example above ? it's right after the text.

> > According to the text model, index 10 is still valid, it's the index between the last character and the implied line break, so tf.getDocument().getText(10, 1) returns \n.
> 
> The last character is implementation detail, it is not part of the "users data" this is the reason why it is excluded from the Document.getLength().

Exactly! It's not part of the text itself, yet the index at `Document.getLength()` is a valid position.

I see no reason why accessible API would consider such a position invalid.

> > Ok, let's step away from the documentation and try to focus on the use case of this method. Method is supposed to expose navigation within the text component to the assistive technology devices and programs. One of such programs (not the only one) is a text narrator. These narrators are meant to be used on text components and they have special shortcuts to narrate the previous and next word or character compared to the current caret position.
> 
> Those narrators should not use the AccessibleText interface blindly. Instead, they should check the specification and decide which methods to call and when. The method in question cannot return the first or last word in some scenarios, so relying on it without understanding its limitations could lead to incorrect behavior.

In an ideal world? And again, *?an index within the text?* is a vague definition which one developer may interpret one way whereas another one may think it's okay. This bug, [JDK-8360070](https://bugs.openjdk.org/browse/JDK-8360070), is the proof for that.

As far as I can see, the implementation of `getIndexAtPoint` can return `Document.getLength()` as an index, which becomes inconsistent: the index is considered valid in some cases but it's invalid in other cases.

I think the proposed fix is backward compatible: it extends the range of valid indexes for a method call; reducing the range would be more problematic.

At the same time, I agree that all implementations of `AccessibleText` need updating to be consistent.

The specification for `AccessibleText` needs updating, too, to avoid any confusion: the valid range for the index parameter has to be explicitly defined such as `> 0 && < model.getLength()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25941#issuecomment-3109915595

From achung at openjdk.org  Wed Jul 23 20:36:14 2025
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 23 Jul 2025 20:36:14 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v26]
In-Reply-To: <qIXtdwoE92RIVk99JaQhjWOiFmeq9omI-wSYA67g95s=.a92dd45e-84da-42a5-beb1-da75ee7c33f1@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <qIXtdwoE92RIVk99JaQhjWOiFmeq9omI-wSYA67g95s=.a92dd45e-84da-42a5-beb1-da75ee7c33f1@github.com>
Message-ID: <RRomBCgHXR2U0M5HA3r15u7cM1MUX0BnEK4tr2uJM-I=.b843ccdd-7101-4eee-b4d2-8d77af556c82@github.com>

On Wed, 23 Jul 2025 19:16:18 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove static from step delay/length fields

removed static from step delay and step length fields

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

PR Comment: https://git.openjdk.org/jdk/pull/22044#issuecomment-3110078802

From dnguyen at openjdk.org  Wed Jul 23 21:10:56 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 23 Jul 2025 21:10:56 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v3]
In-Reply-To: <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>
Message-ID: <-AU40h4yk41qwuvaHvpJAPXIwL7xkEOvzXXuwqYBleM=.170ab823-6eb8-4a1c-8d02-7913902710db@github.com>

On Tue, 22 Jul 2025 08:28:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

I'm able to run the test as is with the changes and the test passes locally and on CI. Some syntax requests but the test looks good so far.

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1430:

> 1428:             indexCounter++;
> 1429:         }
> 1430:         if(indexCounter < maxCounter && values.elementAt(indexCounter).

Suggestion:

        if (indexCounter < maxCounter && values.elementAt(indexCounter).

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 86:

> 84:             });
> 85:             if (isVisible) {
> 86:                 throw new RuntimeException("poup is visible after component is removed");

Suggestion:

                throw new RuntimeException("popup is visible after component is removed");

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

Changes requested by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3049064507
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2226690635
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2226690156

From psadhukhan at openjdk.org  Wed Jul 23 21:10:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Jul 2025 21:10:56 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v3]
In-Reply-To: <E3KxLkDv_b-fXsZwDjil2_46kWtdR8NMRETbMF_IvRs=.c44946f0-4cd6-41d1-9090-b2cd0ad7c0d3@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>
 <E3KxLkDv_b-fXsZwDjil2_46kWtdR8NMRETbMF_IvRs=.c44946f0-4cd6-41d1-9090-b2cd0ad7c0d3@github.com>
Message-ID: <tVDjVKd7ILgV6r9r6wrWMb5svGJCuYK0Suu4l0KRjzE=.db2a3d62-d1b8-4939-a8ff-14ee5d4eb2bb@github.com>

On Tue, 22 Jul 2025 21:42:08 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Test is failing for me on macOS with error: Execution failed: `main' threw exception: java.lang.RuntimeException: poup is visible after component is removed

I have tested and the test is passing in CI both in individual run in all 4 platforms and also as part of clientlibs job
and also I have tested locally in my macos15.5 system where it passed..

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

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3105511024

From bchristi at openjdk.org  Wed Jul 23 22:14:06 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 23 Jul 2025 22:14:06 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
Message-ID: <Z4SxwrX3Yhi7QYEtUkM_IuNHZC0a9OwyHaMx5mLQdDk=.1a4d3791-3a4a-4561-9113-98c8e3c2393b@github.com>

On Wed, 16 Jul 2025 22:45:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Eliminate a finalize() method in the Swing macOS implementation.
>> 
>> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
>> 
>> import javax.swing.JTabbedPane;
>> import javax.swing.plaf.TabbedPaneUI;
>> 
>> public class CreateTabbedPaneUIStressTest {
>> 
>>    public static void main(String[] args) {
>>        for (int i=0; i<1000000000; i++) {
>>            JTabbedPane jtp = new JTabbedPane();
>>            TabbedPaneUI tpui = jtp.getUI();
>>        }
>>    }
>> }
>> 
>> 
>> I also monitored the process size using 'top'.
>> And when I commented out the native call that did the free and re-tested I saw process size grow.
>> 
>> Turning the above into a useful regression test doesn't seem possible to me.
>> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JRSUIControl.java

Marked as reviewed by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26331#pullrequestreview-3049251428

From bchristi at openjdk.org  Wed Jul 23 22:14:07 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 23 Jul 2025 22:14:07 GMT
Subject: RFR: 8362289: [macOS] Remove finalize method in JRSUIControls.java
 [v4]
In-Reply-To: <4EF17yjfvyOmHJFAuVDzC2qG3UuJEyOGO4ZJRhKQz9A=.6c301779-593e-4866-a566-b3b95d4fd214@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
 <Pvcc0MTYzbqD8gBAaLI_pYMK018dM0CZ7Amn1AjUEi4=.f34d5ef2-67bd-411e-8739-ec579820e249@github.com>
 <pa-SZv2RE5utqX3nEFO4yAEknVo-E6MtCLarouLhdR0=.73f12c91-e8c5-4bd1-abe0-fd936ab05bcb@github.com>
 <4EF17yjfvyOmHJFAuVDzC2qG3UuJEyOGO4ZJRhKQz9A=.6c301779-593e-4866-a566-b3b95d4fd214@github.com>
Message-ID: <lFmKz_OhWd4QkhFHE6DgKmqy9wBfP3lUdem2Xi6u5aY=.9f23f174-f1cf-4d51-930f-d7d9934f01f8@github.com>

On Tue, 22 Jul 2025 05:06:03 GMT, Phil Race <prr at openjdk.org> wrote:

> I do not see any scenario in which this is needed. I will evaluate if we need to file a bug to use reachabiltyFence in the Disposer creation since that is a one-time contained thing but I have no reason to suppose it is needed in this class.

OK, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26331#issuecomment-3110566005

From psadhukhan at openjdk.org  Thu Jul 24 02:34:44 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 24 Jul 2025 02:34:44 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v4]
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26407/files
  - new: https://git.openjdk.org/jdk/pull/26407/files/0037a482..7091fb6e

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

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

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

From psadhukhan at openjdk.org  Thu Jul 24 02:34:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 24 Jul 2025 02:34:45 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v3]
In-Reply-To: <-AU40h4yk41qwuvaHvpJAPXIwL7xkEOvzXXuwqYBleM=.170ab823-6eb8-4a1c-8d02-7913902710db@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>
 <-AU40h4yk41qwuvaHvpJAPXIwL7xkEOvzXXuwqYBleM=.170ab823-6eb8-4a1c-8d02-7913902710db@github.com>
Message-ID: <4pbnXhW8TdF_qgZMit2_KPO093ljM30yXVg1shAX7JU=.309ab98e-c5be-4441-86fd-a76ff255c4ae@github.com>

On Wed, 23 Jul 2025 21:07:21 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update
>
> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1430:
> 
>> 1428:             indexCounter++;
>> 1429:         }
>> 1430:         if(indexCounter < maxCounter && values.elementAt(indexCounter).
> 
> Suggestion:
> 
>         if (indexCounter < maxCounter && values.elementAt(indexCounter).

the formatting is consistent with the previous 2 checks so I didn't change, so either I have to change the previous lines formatting too since it will look odd if we change mine and not the previous so I kept it as it is like previous check.

> test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 86:
> 
>> 84:             });
>> 85:             if (isVisible) {
>> 86:                 throw new RuntimeException("poup is visible after component is removed");
> 
> Suggestion:
> 
>                 throw new RuntimeException("popup is visible after component is removed");

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2227173524
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2227176399

From duke at openjdk.org  Thu Jul 24 08:12:15 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 24 Jul 2025 08:12:15 GMT
Subject: RFR: 8361192: Test
 java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java fails on all platforms
 [v2]
In-Reply-To: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
References: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
Message-ID: <gTCFBHo2JxkF4figPBg55cUsfczASVnWyQ7fY2OegUk=.953a2ab9-15e9-47fc-bb17-8ddce8714fa3@github.com>

> Changes heavyweight color to white, for the test to pass.

Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'pr/25971' into jdk-8361192
 - Removes test from Problem List
 - Sets heavyweight background and foreground colors different than the back frame color

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

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

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

From duke at openjdk.org  Thu Jul 24 08:18:32 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 24 Jul 2025 08:18:32 GMT
Subject: RFR: 8361192: Test
 java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java fails on all platforms
 [v3]
In-Reply-To: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
References: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
Message-ID: <IgQDG_RgscMb085M3rcF2a-mRAlWGPFfRNcUCsqH9Hs=.6df0d70a-1c88-4f39-97da-4712c028e128@github.com>

> Changes heavyweight color to white, for the test to pass.

Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:

  Updates copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26167/files
  - new: https://git.openjdk.org/jdk/pull/26167/files/0b83f5d3..acede0c0

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

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

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

From duke at openjdk.org  Thu Jul 24 08:24:59 2025
From: duke at openjdk.org (Khalid Boulanouare)
Date: Thu, 24 Jul 2025 08:24:59 GMT
Subject: RFR: 8361192: Test
 java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java fails on all platforms
 [v3]
In-Reply-To: <IgQDG_RgscMb085M3rcF2a-mRAlWGPFfRNcUCsqH9Hs=.6df0d70a-1c88-4f39-97da-4712c028e128@github.com>
References: <EDfKfAAFUMJz9nXRLdHi_JOG7Vg5CAbkaHknxk61FVE=.4d66b1eb-c08c-43bd-963d-403c3ca99064@github.com>
 <IgQDG_RgscMb085M3rcF2a-mRAlWGPFfRNcUCsqH9Hs=.6df0d70a-1c88-4f39-97da-4712c028e128@github.com>
Message-ID: <_R0OeBTI-t87dgOGVK9RTKxRhgU2200dQybXKM_X0J0=.2ee3d5b4-4edc-48a0-bd79-54246149ad50@github.com>

On Thu, 24 Jul 2025 08:18:32 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Changes heavyweight color to white, for the test to pass.
>
> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates copyright years

Copyright years updated.

Merge-conflict resolved.

@alisenchung 
There are comments in PR https://github.com/openjdk/jdk/pull/26196 on whether we could merge all dependent fixes in PR https://github.com/openjdk/jdk/pull/25971.  

Please advise if this PR could be merged with https://github.com/openjdk/jdk/pull/25971

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

PR Comment: https://git.openjdk.org/jdk/pull/26167#issuecomment-3112523854

From kizune at openjdk.org  Thu Jul 24 08:33:02 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 24 Jul 2025 08:33:02 GMT
Subject: RFR: 8361524: [XWayland] possible JavaFX interop hang
In-Reply-To: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
References: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
Message-ID: <iKqjYwit7OO1UFKEThaeepDHTrqzW7Dn5c0Kpsx_IXc=.36e6c55f-0377-47ee-a0f6-1db08c473910@github.com>

On Mon, 7 Jul 2025 21:41:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Callbacks in the `src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c` file normally have the following pattern:
> 
> 
> helper->isDone = TRUE;
> callbackEnd();
> // return;
> 
> 
> Failing to call `callbackEnd()` could result in a hang if another GTK loop is running (e.g., JavaFX see https://github.com/openjdk/jdk/pull/22131#issue-2660482472).
> 
> This fix corrects this flaw.

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26172#pullrequestreview-3050647811

From dnguyen at openjdk.org  Thu Jul 24 15:28:04 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 24 Jul 2025 15:28:04 GMT
Subject: RFR: 8359416: Test
 'javax/swing/JScrollPane/AcceleratedWheelScrolling/HorizScrollers.java' failed
 on Windows 2025 x64 because there is a failure frame while the test case is
 running
In-Reply-To: <yaK9OSeq3upNWI9d8wBcrA9hfYV9CzXcez_83i0P9ZM=.1bdbe824-37af-4145-a327-0c790da9f66c@github.com>
References: <kXS9oPVA2-69rGfiSjn7N7-PMeEGeoKYy_QBcFgfjZc=.68f7f15f-e363-4c7a-bdd0-f8747ac6dd15@github.com>
 <V2RwVfV4XBSb2-dE2uOTD9QY50ehgAh1qBjPtbWfQgg=.97774559-f939-49c8-97d8-eb026aae17b4@github.com>
 <HL7C1P-P1cPx5Wcqj8YF_NaINgr2ea6fLoFeX4vy07o=.c52c3796-b395-47d6-bdcd-09e86a0a119c@github.com>
 <yaK9OSeq3upNWI9d8wBcrA9hfYV9CzXcez_83i0P9ZM=.1bdbe824-37af-4145-a327-0c790da9f66c@github.com>
Message-ID: <hUHBpa2T_QmENVCmARgeI37BQ5D2biexpAOPXi3BJkY=.8fdae740-361b-471b-8a79-21bcca20ff9b@github.com>

On Thu, 17 Jul 2025 02:28:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > What exactly is the failure thrown in Nimbus L&F? JBS says `PassFailJFrame.forceFail `is called From my running it seems the failure is `"java.lang.RuntimeException: leading cell is not aligned"` It can be a genuine issue for Nimbus since it behaves ok for other L&F..
> > 
> > 
> > I ran into the same issue when I previously checked this. I can submit a Nimbus issue afterwards if needed. Wanted to handle the test here first.
> 
> But you are handling the test failure by just omitting Nimbus run, which is not the way to go about it in my opinion..

I have gone through the changes again and in converting the test, nothing Nimbus specific was touched. I can't re-run the old test due to its reliance on Applet. When converting the test, I don't believe anyone, including myself, tested it on Nimbus since the test doesn't cycle thru all LAFs. The error in Nimbus only seems to be due to `cellRect` sizing not matching `visRect`. I don't see how that's related to the changes in this test, and rather may be a Nimbus issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/26165#issuecomment-3113906220

From abhiscxk at openjdk.org  Thu Jul 24 16:11:55 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 24 Jul 2025 16:11:55 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v3]
In-Reply-To: <tVDjVKd7ILgV6r9r6wrWMb5svGJCuYK0Suu4l0KRjzE=.db2a3d62-d1b8-4939-a8ff-14ee5d4eb2bb@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>
 <E3KxLkDv_b-fXsZwDjil2_46kWtdR8NMRETbMF_IvRs=.c44946f0-4cd6-41d1-9090-b2cd0ad7c0d3@github.com>
 <tVDjVKd7ILgV6r9r6wrWMb5svGJCuYK0Suu4l0KRjzE=.db2a3d62-d1b8-4939-a8ff-14ee5d4eb2bb@github.com>
Message-ID: <90pXYV5q9yzRbF8FfJmWybNpXNlmvL38wTvZTjh52UU=.b9cd2c16-5c4b-44cb-9bfb-e5e420803864@github.com>

On Wed, 23 Jul 2025 03:07:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Test is failing for me on macOS with error: Execution failed: `main' threw exception: java.lang.RuntimeException: poup is visible after component is removed
> 
> I have tested and the test is passing in CI both in individual run in all 4 platforms and also as part of clientlibs job and also I have tested locally in my macos15.5 system where it passed..

Test is failing on macOS for me as well with the same error. I am running Sequoia 15.5 macOS version.

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

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3114046596

From abhiscxk at openjdk.org  Thu Jul 24 16:21:54 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 24 Jul 2025 16:21:54 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v3]
In-Reply-To: <90pXYV5q9yzRbF8FfJmWybNpXNlmvL38wTvZTjh52UU=.b9cd2c16-5c4b-44cb-9bfb-e5e420803864@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <B70yq8hJgpcTfes8JbbaDnLVq4tpZ6t9IV1MlSoXssE=.00c97dd3-ee5f-4f6e-82b9-7b8cfde24fc8@github.com>
 <E3KxLkDv_b-fXsZwDjil2_46kWtdR8NMRETbMF_IvRs=.c44946f0-4cd6-41d1-9090-b2cd0ad7c0d3@github.com>
 <tVDjVKd7ILgV6r9r6wrWMb5svGJCuYK0Suu4l0KRjzE=.db2a3d62-d1b8-4939-a8ff-14ee5d4eb2bb@github.com>
 <90pXYV5q9yzRbF8FfJmWybNpXNlmvL38wTvZTjh52UU=.b9cd2c16-5c4b-44cb-9bfb-e5e420803864@github.com>
Message-ID: <2BLBCc_OhEOHlLSkawZL04zqrHxyAvU4k7aNX6HcmnU=.2f910ec5-84fd-450d-be29-6c99fe78764e@github.com>

On Thu, 24 Jul 2025 16:08:56 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > > Test is failing for me on macOS with error: Execution failed: `main' threw exception: java.lang.RuntimeException: poup is visible after component is removed
> > 
> > 
> > I have tested and the test is passing in CI both in individual run in all 4 platforms and also as part of clientlibs job and also I have tested locally in my macos15.5 system where it passed..
> 
> Test is failing on macOS for me as well with the same error. I am running Sequoia 15.5 macOS version.

It was a mistake from my side.. I didn't build the changes and that's why test failed.
It's working fine with the current fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3114080319

From aivanov at openjdk.org  Thu Jul 24 18:03:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Jul 2025 18:03:00 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v4]
In-Reply-To: <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>
Message-ID: <rcGDZ7g8RCDfQDCUx4m9JFbKSkkyavVXPsLMH05uFLo=.b4afdb7b-594d-4cd9-820f-63e1103a1039@github.com>

On Thu, 24 Jul 2025 02:34:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 129:

> 127:     transient  Frame frame;
> 128:     private    int desiredLocationX,desiredLocationY;
> 129:     transient private PropertyChangeListener propListener;

Suggestion:

    private transient PropertyChangeListener propListener;

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 952:

> 950:                 oldInvoker.removePropertyChangeListener(oldPropListener);
> 951:             }
> 952:             propListener = new PropertyChangeListener() {

I believe one instance of `PropertyChangeListener` is enough. It could be created at the `propListener` field declaration.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 63:

> 61:     }
> 62: 
> 63:     public static void main(String args[]) throws Exception {

Suggestion:

    public static void main(String[] args) throws Exception {

Use Java-style array declaration.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 66:

> 64:         try {
> 65:             Robot robot = new Robot();
> 66:             SwingUtilities.invokeAndWait(() -> createUI());

Suggestion:

            SwingUtilities.invokeAndWait(TestPopupInvoker::createUI);

Method references are preferred in this case.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 69:

> 67:             robot.waitForIdle();
> 68:             robot.delay(1000);
> 69:             SwingUtilities.invokeAndWait(() -> {

Suggestion:

            robot.delay(1000);

            SwingUtilities.invokeAndWait(() -> {

Introduce sections of code to improve readability.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 76:

> 74:                 jpm.show(label, 0, 0);
> 75:                 pt = label.getLocationOnScreen();
> 76:                 size = label.getBounds();

Neither `pt` nor `size` are used.

test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java line 80:

> 78:             robot.waitForIdle();
> 79:             robot.delay(2000);
> 80:             SwingUtilities.invokeAndWait(() -> {

Suggestion:

            robot.delay(2000);

            SwingUtilities.invokeAndWait(() -> {

Introduce sections of code to improve readability.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3052590110
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229138254
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229143184
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229191620
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229193103
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229152876
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229185127
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229184368

From aivanov at openjdk.org  Thu Jul 24 18:53:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Jul 2025 18:53:55 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v4]
In-Reply-To: <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>
Message-ID: <ZM05adWnYE4iyMrTzMmknuV0rsdG1g_PXQEDcQYlub0=.e8ce40b9-9989-4c65-8d7e-eef7e8ce774c@github.com>

On Thu, 24 Jul 2025 02:34:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 961:

> 959:                                 popup.dispose();
> 960:                                 popup = null;
> 961:                             }

This doesn't work for me on Windows.

Well, the test passes because `jpm.isVisible()` returns `false` since `popup` is set to `null`:

https://github.com/openjdk/jdk/blob/4e53a9d9dfe7a1ac7c3d7402e5ca3a3d3fcbb709/src/java.desktop/share/classes/javax/swing/JPopupMenu.java#L881-L883

But the popup itself remains on the screen.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3052849912
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229306411

From prr at openjdk.org  Thu Jul 24 18:59:58 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 24 Jul 2025 18:59:58 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v18]
In-Reply-To: <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
Message-ID: <WUmKoOJcpA9o4q6C_aAZUnTS7ANIYT4YDGxdPnWKCm0=.efa0bf46-ce10-4604-9c72-8576df9892ec@github.com>

On Wed, 23 Jul 2025 08:43:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded vars

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:

> 66:  * no exceptions will be thrown but the image will be 'effectively' null,
> 67:  * as it will have no dimensions and never be drawn, and
> 68:  * getImageLoadStatus() will report {@see java.awt.MediaTracker#ERRORED}.

{@code getImageLoadStatus()}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2229319014

From aivanov at openjdk.org  Thu Jul 24 19:19:56 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Jul 2025 19:19:56 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v4]
In-Reply-To: <ZM05adWnYE4iyMrTzMmknuV0rsdG1g_PXQEDcQYlub0=.e8ce40b9-9989-4c65-8d7e-eef7e8ce774c@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>
 <ZM05adWnYE4iyMrTzMmknuV0rsdG1g_PXQEDcQYlub0=.e8ce40b9-9989-4c65-8d7e-eef7e8ce774c@github.com>
Message-ID: <Rj9SM9AnWeYpE9uBW4_TQXGNxlakCjI4g66EbtooKt8=.fbac2470-c28f-4bc7-a501-96a66aec4f81@github.com>

On Thu, 24 Jul 2025 18:51:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo
>
> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 961:
> 
>> 959:                                 popup.dispose();
>> 960:                                 popup = null;
>> 961:                             }
> 
> This doesn't work for me on Windows.
> 
> Well, the test passes because `jpm.isVisible()` returns `false` since `popup` is set to `null`:
> 
> https://github.com/openjdk/jdk/blob/4e53a9d9dfe7a1ac7c3d7402e5ca3a3d3fcbb709/src/java.desktop/share/classes/javax/swing/JPopupMenu.java#L881-L883
> 
> But the popup itself remains on the screen.

All you have to do is call `setVisible(false)` (possibly ensuring that `isVisible()` returns `true` first).

This will hide the popup menu and fire the relevant events which aren't sent now? and popup remains on the screen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2229366856

From prr at openjdk.org  Thu Jul 24 19:20:59 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 24 Jul 2025 19:20:59 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v18]
In-Reply-To: <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
Message-ID: <jizY9nAzboEGLEOTxGlx0spPjBf-ilw8OqspGVAox90=.3ae44295-6505-40ce-896a-80676893dd26@github.com>

On Wed, 23 Jul 2025 08:43:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded vars

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 54:

> 52: 
> 53:         for (ArgType a : ArgType.values()) {
> 54:             for (final boolean invalid : new boolean[]{false, true}) {

This "invalid==false" means use null and "invalid=true" means use non-null but invalid image data 
seems odd.

Can we rename invalid to "invalidImageData" ? Or may be better an other enum ?

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 103:

> 101:                         passed = true;
> 102:                     }
> 103:                 } catch (Exception ex) {

What's this block for ? What other kind of exception besides NPE can we get ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2229365272
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2229365160

From prr at openjdk.org  Thu Jul 24 19:21:00 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 24 Jul 2025 19:21:00 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v18]
In-Reply-To: <jizY9nAzboEGLEOTxGlx0spPjBf-ilw8OqspGVAox90=.3ae44295-6505-40ce-896a-80676893dd26@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
 <jizY9nAzboEGLEOTxGlx0spPjBf-ilw8OqspGVAox90=.3ae44295-6505-40ce-896a-80676893dd26@github.com>
Message-ID: <Vs-JOXrzv_t16JhmBf7CgV2z9l5T0ic5eA43f3v_uUc=.1881fc13-3505-404e-a3b5-e5d58230c673@github.com>

On Thu, 24 Jul 2025 19:16:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded vars
>
> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 54:
> 
>> 52: 
>> 53:         for (ArgType a : ArgType.values()) {
>> 54:             for (final boolean invalid : new boolean[]{false, true}) {
> 
> This "invalid==false" means use null and "invalid=true" means use non-null but invalid image data 
> seems odd.
> 
> Can we rename invalid to "invalidImageData" ? Or may be better an other enum ?

Like this ?


import java.io.File;
import java.io.FileOutputStream;
import java.net.URL;
import java.util.Random;
import java.awt.Image;
import java.awt.Toolkit;
import javax.swing.ImageIcon;

public class ImageIconTest {

    static enum ArgType { FILE, URL, BYTEARRAY, IMAGE };
    static enum ArgVal { NULL, INVALIDDATA };

    public static void main(String[] args) throws Exception {

        String imgName = "invalid.gif";
        byte[] invalidData = new byte[100];
        new Random().nextBytes(invalidData);
        try (FileOutputStream fos = new FileOutputStream(imgName)) {
            fos.write(invalidData);
        }
        String fileName = (new File(System.getProperty("test.src", "."), imgName)).getName();

        for (ArgType a : ArgType.values()) {
            for (final ArgVal v : ArgVal.values()) {
                System.out.println("Testing for ArgType " + a + " for case " + v);
                boolean expected = true;
                boolean passed = false;
                try {
                    switch (a) {
                       case FILE :
                           expected = false;
                           String s = (v == ArgVal.NULL) ? null : fileName;
                           new ImageIcon(s);
                           passed = true; // no exception expected for this case
                           break;
                       case URL :
                           if (v == ArgVal.NULL) {
                               new ImageIcon((URL)null);
                           } else if (v == ArgVal.INVALIDDATA) {
                               expected = false;
                               new ImageIcon("file://" + imgName, "gif");
                               passed = true; // no exception expected for this case
                           }
                           break;
                       case BYTEARRAY :
                           if (v == ArgVal.NULL) {
                               byte[] bytes = null;
                               new ImageIcon(bytes);
                           } else if (v == ArgVal.INVALIDDATA) {
                               expected = false;
                               new ImageIcon(new byte[0], "gif");
                               passed = true; // no exception expected for this case
                           }
                           break;
                       case IMAGE :
                           if (v == ArgVal.NULL) {
                               new ImageIcon((Image)null);
                           } else if (v == ArgVal.INVALIDDATA) {
                               expected = false;
                               new ImageIcon((Image)Toolkit.getDefaultToolkit().createImage(fileName), "gif");
                               passed = true; // no exception expected for this case
                           }
                           break;
                    }
                } catch (NullPointerException e) {
                    if (expected) {
                        passed = true;
                    }
/*
// I don't know why you have this in your version
                } catch (Exception ex) {
                    if (expected) {
                        passed = true;
                    }
*/
                }
                if (expected && !passed) {
                   System.err.println("Did not receive expected exception for : " + a);
                   throw new RuntimeException("Test failed");
                }
                if (!expected && !passed) {
                   System.err.println("Received unexpected exception for : " + a);
                   throw new RuntimeException("Test failed");
                }
            }
        }

        // test setter
        try {
            ImageIcon ii = new ImageIcon();
            ii.setImage((Image)null);
            throw new RuntimeException("No NPE");
        } catch (NullPointerException e) {
            // expected
        }
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2229369799

From prr at openjdk.org  Thu Jul 24 19:38:59 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 24 Jul 2025 19:38:59 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v18]
In-Reply-To: <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
Message-ID: <2iFCJpbqa829JiDoxDVCio-6sTtSddtoKFMxmCZjoQk=.965dd002-fa58-45c5-b1fa-b9cc59b5f494@github.com>

On Wed, 23 Jul 2025 08:43:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded vars

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 64:

> 62:  * are preloaded using MediaTracker to monitor the loaded state
> 63:  * of the image.
> 64:  * If the image source parameter to a constructor is non-null,

Whilst reviewing the CSR I realized you need to change the line above to say
"If the image source parameter to a constructor or method is non-null,"

I made that change in the CSR. Do it here too. It is needed to cover setImage()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2229416113

From kcr at openjdk.org  Thu Jul 24 19:48:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 24 Jul 2025 19:48:00 GMT
Subject: RFR: 8361524: [XWayland] possible JavaFX interop hang
In-Reply-To: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
References: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
Message-ID: <fxyRtchPhImkMwZOHBd136e4ZyHWvXyrdHgdBjYE780=.803b8fe6-3825-4c1a-98ef-ee1427b9362c@github.com>

On Mon, 7 Jul 2025 21:41:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Callbacks in the `src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c` file normally have the following pattern:
> 
> 
> helper->isDone = TRUE;
> callbackEnd();
> // return;
> 
> 
> Failing to call `callbackEnd()` could result in a hang if another GTK loop is running (e.g., JavaFX see https://github.com/openjdk/jdk/pull/22131#issue-2660482472).
> 
> This fix corrects this flaw.

LGTM

-------------

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/26172#pullrequestreview-3053062324

From prr at openjdk.org  Thu Jul 24 20:55:59 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 24 Jul 2025 20:55:59 GMT
Subject: Integrated: 8362289: [macOS] Remove finalize method in
 JRSUIControls.java
In-Reply-To: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
References: <0j0trCh6G1BJFL2fCALDjz5MXtVWI20umQtt_mpuWqU=.63b5f0c7-680c-4e1b-a492-503ff9efbe08@github.com>
Message-ID: <tTiJS5TkJt2OvpmDKt6ipK5n68w3j9uQESFxV6JXd1w=.5ed1151c-e46d-4f9b-a5d9-ffa0771e0a03@github.com>

On Tue, 15 Jul 2025 19:57:56 GMT, Phil Race <prr at openjdk.org> wrote:

> Eliminate a finalize() method in the Swing macOS implementation.
> 
> I tested that the dispose method is being called by running this small test in combination with some 'println' statements in the source code (now removed)
> 
> import javax.swing.JTabbedPane;
> import javax.swing.plaf.TabbedPaneUI;
> 
> public class CreateTabbedPaneUIStressTest {
> 
>    public static void main(String[] args) {
>        for (int i=0; i<1000000000; i++) {
>            JTabbedPane jtp = new JTabbedPane();
>            TabbedPaneUI tpui = jtp.getUI();
>        }
>    }
> }
> 
> 
> I also monitored the process size using 'top'.
> And when I commented out the native call that did the free and re-tested I saw process size grow.
> 
> Turning the above into a useful regression test doesn't seem possible to me.
> Limiting Java heap is pointless (and I did use -Xmx20m) since it is a native resource that is to be freed and failure to dispose won't show up as a problem without taking down the machine.

This pull request has now been integrated.

Changeset: 971ea23c
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/971ea23c95764e11ed234f657eb28ba7c51862c5
Stats:     19 lines in 1 file changed: 12 ins; 0 del; 7 mod

8362289: [macOS] Remove finalize method in JRSUIControls.java

Reviewed-by: bchristi, serb

-------------

PR: https://git.openjdk.org/jdk/pull/26331

From duke at openjdk.org  Fri Jul 25 02:26:07 2025
From: duke at openjdk.org (duke)
Date: Fri, 25 Jul 2025 02:26:07 GMT
Subject: Withdrawn: 8224968: javax/swing/JColorChooser/Test6827032.java times
 out in Windows 10
In-Reply-To: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
References: <3MCr_BXtTLAnt1pEMH0dW96FXrIMeout345TMUw04Ts=.e0ec91be-0211-4485-8edd-4325c6ed589d@github.com>
Message-ID: <p1hzPxZS4KgYMZTDMFo1q_FOUNhRT0e2GST_eccJNQk=.647f668e-7336-4344-9039-28fb26d265e1@github.com>

On Fri, 28 Feb 2025 15:42:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> **Problem:**
> 
> The test hangs intermittently when run on Windows. (In some cases, handling the timeout takes 2 hours.)
> 
> Thread dump shows no AWT threads, yet jtreg harness still waits for the test thread to finish, in particular it waits for [`StreamCopier`](https://github.com/openjdk/jtreg/blob/759946dedbafa423552851ecb98bc3bb8dcf30ec/src/share/classes/com/sun/javatest/regtest/exec/ProcessCommand.java#L279-L281). See `threaddump.log` attached to the bug and [my comment](https://bugs.openjdk.org/browse/JDK-8224968?focusedId=14757188&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757188) for more details.
> 
> **Fix, or Workaround:**
> 
> Drag mouse for a short while.
> 
> In my testing on CI, the `javax/swing/JColorChooser/Test6827032.java` failed on Windows *3 times* out of 6 runs with 20 repeats (`JTREG=REPEAT_COUNT=20`) without the fix.
> 
> There have been no failures after the fix in 10 runs with 20 repeats.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/23846

From psadhukhan at openjdk.org  Fri Jul 25 03:36:44 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Jul 2025 03:36:44 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v19]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <BOZ10DOvvVfoIcmEzTmrOrsud9KnsIckOtc2pu_s_-E=.8729cdab-84c9-4187-a564-e118ff2d79be@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use code tag and update test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/507e8a40..4b5c98c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=17-18

  Stats: 23 lines in 2 files changed: 1 ins; 8 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/25767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767

PR: https://git.openjdk.org/jdk/pull/25767

From psadhukhan at openjdk.org  Fri Jul 25 03:36:44 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Jul 2025 03:36:44 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v12]
In-Reply-To: <K6XplxZ0jffXV-19bVu3Zuy7scj6tfOUnyI60Oeh7FI=.e4d8df92-99c2-455d-849f-0ab59fd6c0a8@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
 <i4BPuNcD8H3kyeVPAeAPaCvsBJbdG9NxVxVrzvfC58M=.78e4c633-fe9f-44f4-aea9-18483e532b1c@github.com>
 <v90zuPcY6O_xsW3sPIyQpM7PXrvQyRxae3NygbwspuA=.47b79d5c-1461-47ff-a9c1-f107b6d415ce@github.com>
 <K6XplxZ0jffXV-19bVu3Zuy7scj6tfOUnyI60Oeh7FI=.e4d8df92-99c2-455d-849f-0ab59fd6c0a8@github.com>
Message-ID: <qV0Z-XoJhlcdJe39Pn7DIfLbeGHmHF4fSy6iej0cWjg=.e2e035c4-6437-4f4f-ab5b-d4a0f4dda12c@github.com>

On Fri, 11 Jul 2025 18:50:45 GMT, Phil Race <prr at openjdk.org> wrote:

>>> I think we need to have the "whole picture" tested to make sure everything does as we expect. It isn't so easy to tell even from looking at the source of ImageIcon. Then spec'ed so developers know what to expect. When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images Toolkit images are installed, even if they can't be used because the source isn't valid. They are "effectively" null, but not "actually" null. We should at least specify the null arg behaviours and try to say something about invalid image data. And as a result, I am now flipping to just documenting the setImage(null) NPE The protected method loadImage probably needs to say it too. Invalid image data, maybe we can cover that in a class level statement. Note: I'd like to see every constructor tested with both null and invalid image data.
>> 
>> I tested with null image/imagedata and invalid imagedata and it seems only these constructors throw NPE (current JDK) for null image (invalid image doesnt throw any exception)
>> 
>> ImageIcon(image, desc)
>> ImageIcon(image)
>> ImageIcon(byte[], desc)
>> ImageIcon(byte[])
>> 
>> Current PR checks for null in ImageIcon(image) so it will not throw NPE but ImageIcon(byte[]) will still throw..
>> Should we handle those in separate PR and let this only be for setImage(null)?
>
>> > I think we need to have the "whole picture" tested to make sure everything does as we expect. It isn't so easy to tell even from looking at the source of ImageIcon. Then spec'ed so developers know what to expect. When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images Toolkit images are installed, even if they can't be used because the source isn't valid. They are "effectively" null, but not "actually" null. We should at least specify the null arg behaviours and try to say something about invalid image data. And as a result, I am now flipping to just documenting the setImage(null) NPE The protected method loadImage probably needs to say it too. Invalid image data, maybe we can cover that in a class level statement. Note: I'd like to see every constructor tested with both null and invalid image data.
>> 
>> I tested with null image/imagedata and invalid imagedata and it seems only these constructors throw NPE (current JDK) for null image (invalid image doesnt throw any exception)
>> 
>> ImageIcon(image, desc) ImageIcon(image) ImageIcon(byte[], desc) ImageIcon(byte[])
>> 
>> Current PR checks for null in ImageIcon(image) so it will not throw NPE but ImageIcon(byte[]) will still throw.. Should we handle those in separate PR and let this only be for setImage(null)?
> 
> You told me (off-line) that null URL also throws NPE and I see that too.
> 
> This class is a bit of a mess of accidental behaviours and scant documentation.
> 
> Let's document all the NPE behaviours and include a test that verifies it.
> 
> And invalid data like "new byte[0]" or null for a file name,  or pointing to something that isn't an image file, or an invalid URL .. etc .. results in an Image instance being present, but it will never be completed so can never be drawn.
> 
> I think we need a class level statement like
> "If the image source parameter to a constructor is non-null, but does not reference valid accessible image data, no exceptions will be thrown but the image will be 'effectively' null, as it will have no dimensions and never be drawn, and
> getImageLoadStatus() will report ERRORED" - you should verify that last part but I think it is right.
> 
> We probably should add the similar text on setImage().
> 
> We can also test the invalid image data cases too.

@prrace I guess we need to change the bug summary to maybe "Clarify ImageIcon constructors and setImage method for null image parameters and invalid image data" or do you have anything in mind?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3116269718

From psadhukhan at openjdk.org  Fri Jul 25 03:36:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Jul 2025 03:36:45 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v18]
In-Reply-To: <2iFCJpbqa829JiDoxDVCio-6sTtSddtoKFMxmCZjoQk=.965dd002-fa58-45c5-b1fa-b9cc59b5f494@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
 <2iFCJpbqa829JiDoxDVCio-6sTtSddtoKFMxmCZjoQk=.965dd002-fa58-45c5-b1fa-b9cc59b5f494@github.com>
Message-ID: <4uh3cTW1ENlkfDffD0F6Qz8IahrM-ERkY59pR1yREX8=.20dcb1dd-afbf-4491-931a-98e50adafc28@github.com>

On Thu, 24 Jul 2025 19:36:00 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unneeded vars
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 64:
> 
>> 62:  * are preloaded using MediaTracker to monitor the loaded state
>> 63:  * of the image.
>> 64:  * If the image source parameter to a constructor is non-null,
> 
> Whilst reviewing the CSR I realized you need to change the line above to say
> "If the image source parameter to a constructor or method is non-null,"
> 
> I made that change in the CSR. Do it here too. It is needed to cover setImage()

Added

> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 103:
> 
>> 101:                         passed = true;
>> 102:                     }
>> 103:                 } catch (Exception ex) {
> 
> What's this block for ? What other kind of exception besides NPE can we get ?

I added this to handle if "invalid data" handling causes the code to throw IOException or something like that..
But anyways removed now..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2230061559
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2230061369

From psadhukhan at openjdk.org  Fri Jul 25 03:36:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Jul 2025 03:36:45 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v18]
In-Reply-To: <Vs-JOXrzv_t16JhmBf7CgV2z9l5T0ic5eA43f3v_uUc=.1881fc13-3505-404e-a3b5-e5d58230c673@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <v24cXxPJdIO9I7gJfYlcsD5k_ZRvAZ3ugyp6MFMEnL8=.bfc3994d-386d-418b-8715-668c90d6b0ed@github.com>
 <jizY9nAzboEGLEOTxGlx0spPjBf-ilw8OqspGVAox90=.3ae44295-6505-40ce-896a-80676893dd26@github.com>
 <Vs-JOXrzv_t16JhmBf7CgV2z9l5T0ic5eA43f3v_uUc=.1881fc13-3505-404e-a3b5-e5d58230c673@github.com>
Message-ID: <WibgPlS51puu3rUqTqD48FWkb_4OOldn9W6bmM3WGls=.9a011380-9b25-4c05-bd04-9bc59f8eb523@github.com>

On Thu, 24 Jul 2025 19:17:43 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 54:
>> 
>>> 52: 
>>> 53:         for (ArgType a : ArgType.values()) {
>>> 54:             for (final boolean invalid : new boolean[]{false, true}) {
>> 
>> This "invalid==false" means use null and "invalid=true" means use non-null but invalid image data 
>> seems odd.
>> 
>> Can we rename invalid to "invalidImageData" ? Or may be better an other enum ?
>
> Like this ?
> 
> 
> import java.io.File;
> import java.io.FileOutputStream;
> import java.net.URL;
> import java.util.Random;
> import java.awt.Image;
> import java.awt.Toolkit;
> import javax.swing.ImageIcon;
> 
> public class ImageIconTest {
> 
>     static enum ArgType { FILE, URL, BYTEARRAY, IMAGE };
>     static enum ArgVal { NULL, INVALIDDATA };
> 
>     public static void main(String[] args) throws Exception {
> 
>         String imgName = "invalid.gif";
>         byte[] invalidData = new byte[100];
>         new Random().nextBytes(invalidData);
>         try (FileOutputStream fos = new FileOutputStream(imgName)) {
>             fos.write(invalidData);
>         }
>         String fileName = (new File(System.getProperty("test.src", "."), imgName)).getName();
> 
>         for (ArgType a : ArgType.values()) {
>             for (final ArgVal v : ArgVal.values()) {
>                 System.out.println("Testing for ArgType " + a + " for case " + v);
>                 boolean expected = true;
>                 boolean passed = false;
>                 try {
>                     switch (a) {
>                        case FILE :
>                            expected = false;
>                            String s = (v == ArgVal.NULL) ? null : fileName;
>                            new ImageIcon(s);
>                            passed = true; // no exception expected for this case
>                            break;
>                        case URL :
>                            if (v == ArgVal.NULL) {
>                                new ImageIcon((URL)null);
>                            } else if (v == ArgVal.INVALIDDATA) {
>                                expected = false;
>                                new ImageIcon("file://" + imgName, "gif");
>                                passed = true; // no exception expected for this case
>                            }
>                            break;
>                        case BYTEARRAY :
>                            if (v == ArgVal.NULL) {
>                                byte[] bytes = null;
>                                new ImageIcon(bytes);
>                            } else if (v == ArgVal.INVALIDDATA) {
>                                expected = false;
>                                new ImageIcon(new byte[0], "gif");
>                                passed = true; // no exception expected for this case
>                            }
>                            break;
>                        case IMAGE :
>                            if (v == ArgVal.NULL) {
>                                new ImageIcon((Ima...

Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2230063306

From psadhukhan at openjdk.org  Fri Jul 25 05:18:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Jul 2025 05:18:56 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v4]
In-Reply-To: <Rj9SM9AnWeYpE9uBW4_TQXGNxlakCjI4g66EbtooKt8=.fbac2470-c28f-4bc7-a501-96a66aec4f81@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>
 <ZM05adWnYE4iyMrTzMmknuV0rsdG1g_PXQEDcQYlub0=.e8ce40b9-9989-4c65-8d7e-eef7e8ce774c@github.com>
 <Rj9SM9AnWeYpE9uBW4_TQXGNxlakCjI4g66EbtooKt8=.fbac2470-c28f-4bc7-a501-96a66aec4f81@github.com>
Message-ID: <qYniN0s20iOYbCIVkJEFdswv-Dmj42fUWUv38-U5Bfo=.92959c07-8fd9-4c70-b048-7d1a3d9063e3@github.com>

On Thu, 24 Jul 2025 19:17:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 961:
>> 
>>> 959:                                 popup.dispose();
>>> 960:                                 popup = null;
>>> 961:                             }
>> 
>> This doesn't work for me on Windows.
>> 
>> Well, the test passes because `jpm.isVisible()` returns `false` since `popup` is set to `null`:
>> 
>> https://github.com/openjdk/jdk/blob/4e53a9d9dfe7a1ac7c3d7402e5ca3a3d3fcbb709/src/java.desktop/share/classes/javax/swing/JPopupMenu.java#L881-L883
>> 
>> But the popup itself remains on the screen.
>
> All you have to do is call `setVisible(false)` (possibly ensuring that `isVisible()` returns `true` first).
> 
> This will hide the popup menu and fire the relevant events which aren't sent now? and popup remains on the screen.

Hmm..that is strange..it used to work I am sure..let me check..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2230157214

From smandalika at openjdk.org  Fri Jul 25 05:38:31 2025
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Fri, 25 Jul 2025 05:38:31 GMT
Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java
Message-ID: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>

The java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java test uses object monitors and wait/notify to synchronise actions in the test.

Using CountDownLatch could make the test simpler, shorter, clearer.
Tested the code on a windows-x64, macos-x64 and lnux-x64 machines and the test is working as expected.

-------------

Commit messages:
 - 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java

Changes: https://git.openjdk.org/jdk/pull/26471/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26471&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339791
  Stats: 40 lines in 1 file changed: 4 ins; 22 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/26471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26471/head:pull/26471

PR: https://git.openjdk.org/jdk/pull/26471

From psadhukhan at openjdk.org  Fri Jul 25 05:43:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Jul 2025 05:43:56 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v4]
In-Reply-To: <qYniN0s20iOYbCIVkJEFdswv-Dmj42fUWUv38-U5Bfo=.92959c07-8fd9-4c70-b048-7d1a3d9063e3@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>
 <ZM05adWnYE4iyMrTzMmknuV0rsdG1g_PXQEDcQYlub0=.e8ce40b9-9989-4c65-8d7e-eef7e8ce774c@github.com>
 <Rj9SM9AnWeYpE9uBW4_TQXGNxlakCjI4g66EbtooKt8=.fbac2470-c28f-4bc7-a501-96a66aec4f81@github.com>
 <qYniN0s20iOYbCIVkJEFdswv-Dmj42fUWUv38-U5Bfo=.92959c07-8fd9-4c70-b048-7d1a3d9063e3@github.com>
Message-ID: <XHkVzo_zwzYHXz84FDkBEvYrpu3DnzKN3UFk37O-wMA=.1f484b70-295a-4d08-8c5f-84844806f5a5@github.com>

On Fri, 25 Jul 2025 05:15:50 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> All you have to do is call `setVisible(false)` (possibly ensuring that `isVisible()` returns `true` first).
>> 
>> This will hide the popup menu and fire the relevant events which aren't sent now? and popup remains on the screen.
>
> Hmm..that is strange..it used to work I am sure..let me check..

probably we should use hide() instead to allow it to dispose() the resources..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2230198864

From psadhukhan at openjdk.org  Fri Jul 25 07:08:56 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Jul 2025 07:08:56 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v4]
In-Reply-To: <XHkVzo_zwzYHXz84FDkBEvYrpu3DnzKN3UFk37O-wMA=.1f484b70-295a-4d08-8c5f-84844806f5a5@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <w6A9o5LgRKUNKfFG-7HQMRAVEPhz1Fm1IB_PIaJ3tkY=.58427f7c-ee8d-4b9b-856d-2270b29d1b1b@github.com>
 <ZM05adWnYE4iyMrTzMmknuV0rsdG1g_PXQEDcQYlub0=.e8ce40b9-9989-4c65-8d7e-eef7e8ce774c@github.com>
 <Rj9SM9AnWeYpE9uBW4_TQXGNxlakCjI4g66EbtooKt8=.fbac2470-c28f-4bc7-a501-96a66aec4f81@github.com>
 <qYniN0s20iOYbCIVkJEFdswv-Dmj42fUWUv38-U5Bfo=.92959c07-8fd9-4c70-b048-7d1a3d9063e3@github.com>
 <XHkVzo_zwzYHXz84FDkBEvYrpu3DnzKN3UFk37O-wMA=.1f484b70-295a-4d08-8c5f-84844806f5a5@github.com>
Message-ID: <ke2yBB3HhB9oNaAqZX3GLI1Uiy-zLTnFSaUTjFMPgMY=.e0368997-c000-4a91-ad69-f8670a643fe6@github.com>

On Fri, 25 Jul 2025 05:41:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Hmm..that is strange..it used to work I am sure..let me check..
>
> probably we should use hide() instead to allow it to dispose() the resources..

ok setVisible(false) inturn will call hide

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2230331902

From psadhukhan at openjdk.org  Fri Jul 25 07:31:42 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Jul 2025 07:31:42 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v5]
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use setVisible(false) instead of dispose, update test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26407/files
  - new: https://git.openjdk.org/jdk/pull/26407/files/7091fb6e..c5da4598

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26407&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26407&range=03-04

  Stats: 38 lines in 2 files changed: 15 ins; 19 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26407/head:pull/26407

PR: https://git.openjdk.org/jdk/pull/26407

From duke at openjdk.org  Fri Jul 25 11:41:04 2025
From: duke at openjdk.org (ExE Boss)
Date: Fri, 25 Jul 2025 11:41:04 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v19]
In-Reply-To: <BOZ10DOvvVfoIcmEzTmrOrsud9KnsIckOtc2pu_s_-E=.8729cdab-84c9-4187-a564-e118ff2d79be@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <BOZ10DOvvVfoIcmEzTmrOrsud9KnsIckOtc2pu_s_-E=.8729cdab-84c9-4187-a564-e118ff2d79be@github.com>
Message-ID: <or8tnAVzulcSMuNEGXzu6lG6_Nz6eOdDIRb2zn6YfGU=.0d7133d7-e6cc-4964-ac02-d04f2ca202a4@github.com>

On Fri, 25 Jul 2025 03:36:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use code tag and update test

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 42:

> 40: 
> 41:     static enum ArgType { FILE, URL, BYTEARRAY, IMAGE };
> 42:     static enum ArgVal { NULL, INVALIDDATA };

Maybe?name?this `INVALID_DATA`:
Suggestion:

    static enum ArgVal { NULL, INVALID_DATA };

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2230870538

From prr at openjdk.org  Fri Jul 25 18:14:19 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 25 Jul 2025 18:14:19 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v26]
In-Reply-To: <qIXtdwoE92RIVk99JaQhjWOiFmeq9omI-wSYA67g95s=.a92dd45e-84da-42a5-beb1-da75ee7c33f1@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <qIXtdwoE92RIVk99JaQhjWOiFmeq9omI-wSYA67g95s=.a92dd45e-84da-42a5-beb1-da75ee7c33f1@github.com>
Message-ID: <75YbhzZuU7f-pA0i8GgK2iCBF8bJP1GKtntdLbc6qEQ=.0330ef89-8dc7-46b3-92fa-f447ed2470b4@github.com>

On Wed, 23 Jul 2025 19:16:18 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove static from step delay/length fields

src/java.desktop/share/classes/java/awt/Robot.java line 879:

> 877:      * @param   destY  Destination point y coordinate
> 878:      *
> 879:      * @throws  IllegalArgumentException if {@code stepLength} is greater than the distance

In the CSR Joe asked if glide(int, int) needed to throw IAE and it made me look here and I don't actually see where this code would throw that. 
And the old extended robot never had such a feature, did it ?
Also if you think of glide as a sequence of steps, then even with the default of "2" if the distance to move is say "5" after 2 steps you are one pixel away and then I presume we just step one pixel for the final step.
So how is that different than STARTING one pixel away ?

Perhaps we can just dispense with the IAE and if dist < steplength then there's just one step.

test/jdk/lib/client/ExtendedRobot.java line 253:

> 251:      * @see     #delay(int)
> 252:      */
> 253:      public void glide(int srcX, int srcY, int destX, int destY, int stepLength, int speed) {

I hadn't noticed that this over-ride is both removed here and not added to Robot.
If this were available, then perhaps those setters and getters for the current values aren't needed !
What was the reason for not including it ? No one ever used it or something else ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2231743079
PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2231735770

From prr at openjdk.org  Fri Jul 25 19:22:59 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 25 Jul 2025 19:22:59 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v19]
In-Reply-To: <BOZ10DOvvVfoIcmEzTmrOrsud9KnsIckOtc2pu_s_-E=.8729cdab-84c9-4187-a564-e118ff2d79be@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <BOZ10DOvvVfoIcmEzTmrOrsud9KnsIckOtc2pu_s_-E=.8729cdab-84c9-4187-a564-e118ff2d79be@github.com>
Message-ID: <QZOXeyT-DuTzxVklugCzUqhzasytjfVa0kKBdJDLDxs=.c6b85d96-9e78-4a90-828a-563a22566ac5@github.com>

On Fri, 25 Jul 2025 03:36:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use code tag and update test

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 64:

> 62:  * are preloaded using MediaTracker to monitor the loaded state
> 63:  * of the image.
> 64:  * If the image source parameter to a constructor or method is non-null,

FWIW when I first suggested this statement I said it needed to cover the setter too
'We probably should add the similar text on setImage().'
I guess we can keep it here now it's here.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 66:

> 64:  * If the image source parameter to a constructor or method is non-null,
> 65:  * but does not reference valid accessible image data,
> 66:  * no exceptions will be thrown but the image will be 'effectively' null,

Joe asked for if there's an alternative to 'effectively' null. I'm open to suggestions. "unset" ?

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 184:

> 182:      * be preloaded by using MediaTracker to monitor the loaded state
> 183:      * of the image.
> 184:      * Passing {@code null} URL will result in {@code NullPointerException}.

In the CSR, Joe quite reasonably requested that these all become @throws clauses

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 117:

> 115:             ii.setImage((Image)null);
> 116:             throw new RuntimeException("No NPE");
> 117:         } catch (NullPointerException e) {

It occurred to me that you could include this in the switch with a new ARGTYPE of "SETIMAGE".
Bit of a misnomer as its the type + the method but then you can also check the non-null invalid data type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2231847301
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2231851526
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2231839373
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2231842617

From aivanov at openjdk.org  Fri Jul 25 21:33:09 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Jul 2025 21:33:09 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
Message-ID: <VVHXcyKigp91z1dFVT4CHjSdTDDg0GuwrReuTY9XcwM=.1e316206-9bd1-4072-93d0-508d75e4435f@github.com>

On Fri, 18 Jul 2025 13:19:10 GMT, Christian Heilmann <duke at openjdk.org> wrote:

>> This PR fixes a bug that caused no or the wrong set of pages to be printed when using page ranges on macOS.
>> 
>> The main fix is to change the 'location' value of the returned NSRange from the knowsPageRange method to 1 in the native class PrinterView.m.
>
> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>  - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266
>  - Merge branch 'master' into pr/11266
>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS

The suggested fix works.

However, the fix resets the known range of pages to the full range of the document. Is it because the native code doesn't care about the range and it's handled in Java side?

Wouldn't it be easier then to always return `NO` from `knowsPageRange`? The `fTotalPages` field can be dropped from the `PrinterView` class.

src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m line 149:

> 147:     else
> 148:     {
> 149:         aRange->length = fTotalPages;

But why didn't the old code work? If a range is set to 2-3, we know exactly the number of pages to print, and this number is 2.

Does it work correctly if `mDocument.getNumberOfPages()` in `CPrinterJob.java` returns a certain number instead of `UNKNOWN_NUMBER_OF_PAGES`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/11266#pullrequestreview-3056811385
PR Review Comment: https://git.openjdk.org/jdk/pull/11266#discussion_r2232022179

From honkar at openjdk.org  Fri Jul 25 23:43:17 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Jul 2025 23:43:17 GMT
Subject: RFR: JDK-8361748 : Enforce limits on the size of an XBM image
Message-ID: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>

XBM (X Bitmap) images are small one-bit deep images that were developed as a simple uncompressed format that could easily be included in C source files as include files.

Format of XBM image:


 #define width w
 #define height h
 static char foo_bits[] = {
 0xnn,0xnn,0xnn,0xnn,0xnn, .......
 0xnn,0xnn,0xnn,0xnn, .........
 0xnn,0xnn,0xnn,0xnn};


The first two #defines statements specify the width and height of the bitmap in pixels followed by hex byte array which represent pixel data itself.

The current implementation allows an arbitrarily large XBM which is not a valid use case for any XBM.
Also it doesn't validate that the provided byte array is sufficient to populate the specified WxH. Since these are small one-bit mono images we have set a reasonable size limit to  `MAX_XBM_SIZE = 16384 bytes`. This can be set to a larger limit if someone thinks it is necessary.

The XBMDecoder's produceImage() has outdated logic, it has been restructured by adding more efficient parser logic and better error handling checks.

-------------

Commit messages:
 - regression test
 - src code changes

Changes: https://git.openjdk.org/jdk/pull/26488/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26488&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361748
  Stats: 234 lines in 7 files changed: 148 ins; 25 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/26488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26488/head:pull/26488

PR: https://git.openjdk.org/jdk/pull/26488

From honkar at openjdk.org  Fri Jul 25 23:58:39 2025
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Jul 2025 23:58:39 GMT
Subject: RFR: JDK-8361748 : Enforce limits on the size of an XBM image [v2]
In-Reply-To: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
References: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
Message-ID: <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>

> XBM (X Bitmap) images are small one-bit deep images that were developed as a simple uncompressed format that could easily be included in C source files as include files.
> 
> Format of XBM image:
> 
> 
>  #define width w
>  #define height h
>  static char foo_bits[] = {
>  0xnn,0xnn,0xnn,0xnn,0xnn, .......
>  0xnn,0xnn,0xnn,0xnn, .........
>  0xnn,0xnn,0xnn,0xnn};
> 
> 
> The first two #defines statements specify the width and height of the bitmap in pixels followed by hex byte array which represent pixel data itself.
> 
> The current implementation allows an arbitrarily large XBM which is not a valid use case for any XBM.
> Also it doesn't validate that the provided byte array is sufficient to populate the specified WxH. Since these are small one-bit mono images we have set a reasonable size limit to  `MAX_XBM_SIZE = 16384 bytes`. This can be set to a larger limit if someone thinks it is necessary.
> 
> The XBMDecoder's produceImage() has outdated logic, it has been restructured by adding more efficient parser logic and better error handling checks.

Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:

 - rename
 - test summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26488/files
  - new: https://git.openjdk.org/jdk/pull/26488/files/6bbe3e73..f3df2849

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26488&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26488&range=00-01

  Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/26488.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26488/head:pull/26488

PR: https://git.openjdk.org/jdk/pull/26488

From kizune at openjdk.org  Sat Jul 26 02:56:04 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 26 Jul 2025 02:56:04 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v36]
In-Reply-To: <FVhRfLRjStIosXDDhAVCkQxYLnnel4fpqAFly3UhnrA=.fd1ec703-4ae4-4312-b38b-028afe57d2b1@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <FVhRfLRjStIosXDDhAVCkQxYLnnel4fpqAFly3UhnrA=.fd1ec703-4ae4-4312-b38b-028afe57d2b1@github.com>
Message-ID: <Ohf9ndmpLM3d3m8vYT4FwtsmGLlk-G_zsaoAm-es_d4=.4dca2f61-f668-4c61-89a9-24e84405fb5f@github.com>

On Thu, 17 Jul 2025 02:18:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Windows version check

Ok, on Windows 10 it kind of works but there's some confusion about the radio button's check mark size. Here: 
<img width="359" height="350" alt="w10latest" src="https://github.com/user-attachments/assets/f52007ea-6aaf-4a08-b98b-ca8deabdb424" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3121055412

From psadhukhan at openjdk.org  Sun Jul 27 07:02:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 27 Jul 2025 07:02:16 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v20]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <QHtLXfWpE_Y0U8K92rsncAfMYD0RVqPd0N8L8aA5FNc=.5fcdd1ec-3dd6-4926-b25e-9f318fdf8dd6@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  javadoc update using @throws, update test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/4b5c98c3..7dbb4adc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=18-19

  Stats: 37 lines in 2 files changed: 16 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/25767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767

PR: https://git.openjdk.org/jdk/pull/25767

From psadhukhan at openjdk.org  Sun Jul 27 07:02:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 27 Jul 2025 07:02:16 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v19]
In-Reply-To: <QZOXeyT-DuTzxVklugCzUqhzasytjfVa0kKBdJDLDxs=.c6b85d96-9e78-4a90-828a-563a22566ac5@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <BOZ10DOvvVfoIcmEzTmrOrsud9KnsIckOtc2pu_s_-E=.8729cdab-84c9-4187-a564-e118ff2d79be@github.com>
 <QZOXeyT-DuTzxVklugCzUqhzasytjfVa0kKBdJDLDxs=.c6b85d96-9e78-4a90-828a-563a22566ac5@github.com>
Message-ID: <kG-4XQ5nG8yu8Dm-k8qfhIKzJCI2eD2RmwxorNFh0Ho=.e5b35d46-467b-441b-9258-a9b8abeb8d4c@github.com>

On Fri, 25 Jul 2025 19:20:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use code tag and update test
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 66:
> 
>> 64:  * If the image source parameter to a constructor or method is non-null,
>> 65:  * but does not reference valid accessible image data,
>> 66:  * no exceptions will be thrown but the image will be 'effectively' null,
> 
> Joe asked for if there's an alternative to 'effectively' null. I'm open to suggestions. "unset" ?

"unset" sounded better..modified..

> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 184:
> 
>> 182:      * be preloaded by using MediaTracker to monitor the loaded state
>> 183:      * of the image.
>> 184:      * Passing {@code null} URL will result in {@code NullPointerException}.
> 
> In the CSR, Joe quite reasonably requested that these all become @throws clauses

ok..done..

> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 117:
> 
>> 115:             ii.setImage((Image)null);
>> 116:             throw new RuntimeException("No NPE");
>> 117:         } catch (NullPointerException e) {
> 
> It occurred to me that you could include this in the switch with a new ARGTYPE of "SETIMAGE".
> Bit of a misnomer as its the type + the method but then you can also check the non-null invalid data type.

ok..moved..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2233797122
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2233795231
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2233795998

From psadhukhan at openjdk.org  Sun Jul 27 07:02:16 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 27 Jul 2025 07:02:16 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v19]
In-Reply-To: <or8tnAVzulcSMuNEGXzu6lG6_Nz6eOdDIRb2zn6YfGU=.0d7133d7-e6cc-4964-ac02-d04f2ca202a4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <BOZ10DOvvVfoIcmEzTmrOrsud9KnsIckOtc2pu_s_-E=.8729cdab-84c9-4187-a564-e118ff2d79be@github.com>
 <or8tnAVzulcSMuNEGXzu6lG6_Nz6eOdDIRb2zn6YfGU=.0d7133d7-e6cc-4964-ac02-d04f2ca202a4@github.com>
Message-ID: <9HMHOh63BCCGzlB0hcE2eKQzSnnQKncc0eGA7aqQd3M=.6adebc62-bbd2-4dfe-9722-6c95e37ce734@github.com>

On Fri, 25 Jul 2025 11:37:45 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use code tag and update test
>
> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 42:
> 
>> 40: 
>> 41:     static enum ArgType { FILE, URL, BYTEARRAY, IMAGE };
>> 42:     static enum ArgVal { NULL, INVALIDDATA };
> 
> Maybe?name?this `INVALID_DATA`:
> Suggestion:
> 
>     static enum ArgVal { NULL, INVALID_DATA };

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2233795108

From psadhukhan at openjdk.org  Sun Jul 27 07:05:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 27 Jul 2025 07:05:53 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v21]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <2HA1L3X8pmT1J6OKI9TA04cLPFWagoblT-W8fbTEpbg=.721ff0e2-f9d8-4a41-9cb7-dfedab5500df@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  add throws clause

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/7dbb4adc..7d8141ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=19-20

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767

PR: https://git.openjdk.org/jdk/pull/25767

From psadhukhan at openjdk.org  Sun Jul 27 07:08:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 27 Jul 2025 07:08:47 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v22]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  ArgType name change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/7d8141ae..69708ca2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=20-21

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767

PR: https://git.openjdk.org/jdk/pull/25767

From psadhukhan at openjdk.org  Sun Jul 27 07:16:02 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Sun, 27 Jul 2025 07:16:02 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v36]
In-Reply-To: <FVhRfLRjStIosXDDhAVCkQxYLnnel4fpqAFly3UhnrA=.fd1ec703-4ae4-4312-b38b-028afe57d2b1@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <FVhRfLRjStIosXDDhAVCkQxYLnnel4fpqAFly3UhnrA=.fd1ec703-4ae4-4312-b38b-028afe57d2b1@github.com>
Message-ID: <eCpPcLQCzhSMmIbaCudrL8iz0fXdXzXMMxUSDg7yTiY=.b71dda32-21c8-46c2-8c14-5c1f4799970e@github.com>

On Thu, 17 Jul 2025 02:18:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
>> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove Windows version check

> Ok, on Windows 10 it kind of works but there's some confusion about the radio button's check mark size. Here: <img alt="w10latest" width="359" height="350" src="https://private-user-images.githubusercontent.com/69642324/471031541-f52007ea-6aaf-4a08-b98b-ca8deabdb424.PNG?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTM2MDA0MTEsIm5iZiI6MTc1MzYwMDExMSwicGF0aCI6Ii82OTY0MjMyNC80NzEwMzE1NDEtZjUyMDA3ZWEtNmFhZi00YTA4LWI5OGItY2E4ZGVhYmRiNDI0LlBORz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA3MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNzI3VDA3MDgzMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTU5NDE3OTE0NDNkZTNlZjhiM2M2MWNmMDhiNzMwNGE4ODk4MzNmMzdmZTcwZjg4NTFkNThjZjJmZjRhZTI5MmMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.jcKFjs2YyjYvV-oqFfd_wsNWcaJ15tu1jPo_wOZa3mw">

Thanks for your testing on Windows 10.
Did you update your Windows 10 to latest version? 
I guess it was told by Microsoft as reported by Phil that "the visual "cue" we've relied on for in Windows 10 was just an accident of some theming that is now gone. 

so I thought the skin background blue effect would have been replaced in the "new theme"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3124142950

From kizune at openjdk.org  Sun Jul 27 09:59:06 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Sun, 27 Jul 2025 09:59:06 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v36]
In-Reply-To: <eCpPcLQCzhSMmIbaCudrL8iz0fXdXzXMMxUSDg7yTiY=.b71dda32-21c8-46c2-8c14-5c1f4799970e@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <FVhRfLRjStIosXDDhAVCkQxYLnnel4fpqAFly3UhnrA=.fd1ec703-4ae4-4312-b38b-028afe57d2b1@github.com>
 <eCpPcLQCzhSMmIbaCudrL8iz0fXdXzXMMxUSDg7yTiY=.b71dda32-21c8-46c2-8c14-5c1f4799970e@github.com>
Message-ID: <-sTaNO0-W1ESyxmOUW4GqIJLPHHHCX27wJwOTSUc0-s=.5d905699-24b9-40b6-b4ec-a1c68c9f80e9@github.com>

On Sun, 27 Jul 2025 07:13:31 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Did you update your Windows 10 to latest version? I guess it was told by Microsoft as reported by Phil that "the visual "cue" we've relied on for in Windows 10 was just an accident of some theming that is now gone.
> 
> so I thought the skin background blue effect would have been replaced in the "new theme"

Yes, i'm on the latest version of Windows 10. I think what Microsoft rep meant is that this behavior was fixed in Windows 11 but i do not think they ever tried to fix it in W10 and now when W10 is at the EOL they never will.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3124274854

From psadhukhan at openjdk.org  Mon Jul 28 09:20:06 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 28 Jul 2025 09:20:06 GMT
Subject: RFR: 8364146: JList getScrollableUnitIncrement return 0
Message-ID: <VhYDN5ks2RsKEgVbmywg1Zs7NLRilt2dckSOYyRnH1E=.a6bd9446-4c55-4914-ada1-7777239750fe@github.com>

It seems JList.getScrollableUnitIncrement can sometime return 0 instead of positive number which is not specified in the javadoc which can lead to confusion. Clarified javadoc as to when it can return 0.

-------------

Commit messages:
 - 8364146: JList getScrollableUnitIncrement return 0

Changes: https://git.openjdk.org/jdk/pull/26500/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26500&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364146
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26500.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26500/head:pull/26500

PR: https://git.openjdk.org/jdk/pull/26500

From psadhukhan at openjdk.org  Mon Jul 28 10:07:57 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 28 Jul 2025 10:07:57 GMT
Subject: RFR: 8363676: [GCC static analyzer] missing return value check of
 malloc in OGLContext_SetTransform
In-Reply-To: <NGuc7jn_Rduk6kikLMxo9eHanlG3LE6MFr-6MGSSz14=.1b650db7-0889-49d1-9198-01ada7ab5ce8@github.com>
References: <NGuc7jn_Rduk6kikLMxo9eHanlG3LE6MFr-6MGSSz14=.1b650db7-0889-49d1-9198-01ada7ab5ce8@github.com>
Message-ID: <LWcTmMJMYkREYFZurP7RDrGf-Ifi4xhKCz0Yo5WukOQ=.df3a5f32-2221-4a64-9161-8a5f959724c1@github.com>

On Wed, 23 Jul 2025 13:50:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the GCC static analyzer (-fanalyzer) the following issue is reported :
> `src/java.desktop/share/native/common/java2d/opengl/OGLContext.c:487:9: warning: use of possibly-NULL '*oglc.xformMatrix' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]`
> 
> Seems we miss a NULL check of the return value of malloc (at most other places in the coding we do it).

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26443#pullrequestreview-3061709330

From aoqi at openjdk.org  Mon Jul 28 10:24:49 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 28 Jul 2025 10:24:49 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng on
 LoongArch64
Message-ID: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>

After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.


#ifndef PNG_LOONGARCH_LSX_OPT
# if defined(__loongarch_sx)
# define PNG_LOONGARCH_LSX_OPT 1
# else
# define PNG_LOONGARCH_LSX_OPT 0
# endif
#endif


Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

-------------

Commit messages:
 - 8364177: JDK fails to build due to undefined symbol in libpng on LoongArch64

Changes: https://git.openjdk.org/jdk/pull/26501/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26501&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364177
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26501/head:pull/26501

PR: https://git.openjdk.org/jdk/pull/26501

From mbaesken at openjdk.org  Mon Jul 28 11:35:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Jul 2025 11:35:58 GMT
Subject: RFR: 8363676: [GCC static analyzer] missing return value check of
 malloc in OGLContext_SetTransform
In-Reply-To: <NGuc7jn_Rduk6kikLMxo9eHanlG3LE6MFr-6MGSSz14=.1b650db7-0889-49d1-9198-01ada7ab5ce8@github.com>
References: <NGuc7jn_Rduk6kikLMxo9eHanlG3LE6MFr-6MGSSz14=.1b650db7-0889-49d1-9198-01ada7ab5ce8@github.com>
Message-ID: <CFT0Jy7OkdJsTf3DokZORdKSGjSxhYZnBcngt8G3GhQ=.5eab3709-6779-4785-b142-da504a7bdf1e@github.com>

On Wed, 23 Jul 2025 13:50:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the GCC static analyzer (-fanalyzer) the following issue is reported :
> `src/java.desktop/share/native/common/java2d/opengl/OGLContext.c:487:9: warning: use of possibly-NULL '*oglc.xformMatrix' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]`
> 
> Seems we miss a NULL check of the return value of malloc (at most other places in the coding we do it).

Thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26443#issuecomment-3126802611

From mbaesken at openjdk.org  Mon Jul 28 11:35:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Jul 2025 11:35:59 GMT
Subject: Integrated: 8363676: [GCC static analyzer] missing return value check
 of malloc in OGLContext_SetTransform
In-Reply-To: <NGuc7jn_Rduk6kikLMxo9eHanlG3LE6MFr-6MGSSz14=.1b650db7-0889-49d1-9198-01ada7ab5ce8@github.com>
References: <NGuc7jn_Rduk6kikLMxo9eHanlG3LE6MFr-6MGSSz14=.1b650db7-0889-49d1-9198-01ada7ab5ce8@github.com>
Message-ID: <On6FUyA9hgfSU6jQS2nfrCH7_rjWsfXN1oJbGefsm08=.2d3d5691-bc7c-4494-bb65-329af9bcd4c9@github.com>

On Wed, 23 Jul 2025 13:50:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When using the GCC static analyzer (-fanalyzer) the following issue is reported :
> `src/java.desktop/share/native/common/java2d/opengl/OGLContext.c:487:9: warning: use of possibly-NULL '*oglc.xformMatrix' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]`
> 
> Seems we miss a NULL check of the return value of malloc (at most other places in the coding we do it).

This pull request has now been integrated.

Changeset: d25ad881
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d25ad881ebfec40ca6b0a73f78d1f9d2cb722e01
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8363676: [GCC static analyzer] missing return value check of malloc in OGLContext_SetTransform

Reviewed-by: psadhukhan

-------------

PR: https://git.openjdk.org/jdk/pull/26443

From aivanov at openjdk.org  Mon Jul 28 12:51:05 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 12:51:05 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v10]
In-Reply-To: <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
References: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
 <by1L3sa9jQ2bs5TPpK5Mx6dlE9lyfVEDcpJDYH3Cvow=.12d23c02-e3df-4172-af83-7c72c0955a21@github.com>
Message-ID: <McUJkDla7458K0vf7U1bEVjmla1a_3eUehKZtyjssp0=.3b6a5d5e-e1a8-4a15-ba98-72b6d75ced50@github.com>

On Mon, 9 Dec 2024 09:56:15 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731)
>> 
>> This is tracked in JBS as
>> - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731)
>> 
>> According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input)
>> 
>> `alt` is not an attribute of the `input` element.
>> 
>> According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : 
>> 
>>> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ...
>> 
>> This feature is not implemented in `FormView.java`.
>> 
>> ??  ~~This also affects the HTML 32 DTD~~
>> 
>> ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138)
>> 
>> Left before the patch and right after the patch.
>> 
>> 
>> import java.awt.BorderLayout;
>> import java.awt.Dimension;
>> import javax.swing.JEditorPane;
>> import javax.swing.JFrame;
>> import javax.swing.JScrollPane;
>> import javax.swing.SwingUtilities;
>> import javax.swing.text.Document;
>> import javax.swing.text.html.HTMLEditorKit;
>> import javax.swing.text.html.StyleSheet;
>> 
>> public class HTMLAddsSupportAltInputTag {
>>   public static void main(String[] args) {
>>     new HTMLAddsSupportAltInputTag();
>>   }
>>   
>>   public HTMLAddsSupportAltInputTag() {
>>     SwingUtilities.invokeLater(new Runnable(){
>>       public void run(){
>>         JEditorPane jEditorPane = new JEditorPane();
>>         jEditorPane.setEditable(false);
>>         JScrollPane scrollPane = new JScrollPane(jEditorPane);
>>         HTMLEditorKit kit = new HTMLEditorKit();
>>         jEditorPane.setEditorKit(kit);
>>         StyleSheet styleSheet = kit.getStyleSheet();
>>         styleSheet.addRule("""
>>             body {
>>                 color: #000;
>>                 font-family:times;
>>                 margin: 4px;
>>             }
>>             """);
>>         String htmlString = """
>>             <html>
>>                 <body>
>>                     <input type=image name=point src="file:oracle_logo_50x50.jpg" alt="Logo Oracle JPG">
>>                     <p>
>>                     <input type=image name=point src="file:none_ora...
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge master
>  - JDK-8314731 : Remove all indentations accidentally introduced by the previous commit.
>  - Merge master
>  - Merge master
>  - jdk-8314731 : FormView Alt Support.
>    
>    FormView.java :
>    - revert ALL unrelated changing to formatting.
>    
>    bug8314731.java :
>    - Fix the test description.
>    - Change where the user interface is created.
>    - Add a finall block to be sure the Frame is disposed.
>    - Replace "testPassed" with "testFailed".
>  - Merge master
>  - Replaces this title with "alt attribute test in HTML image type input".
>    
>    Moves this test to /jdk/test/jdk/javax/swing/text/html.
>  - bug8314731.java : Corrects the CopyRight date.
>  - FormView.java :
>    Removes a whitespace
>    
>    bug8314731.java :
>    Adds a newline at end of file.
>  - getMaximumSpan(int axis) method
>    doc -> Not used
>    
>    mouseReleased(MouseEvent evt) method
>    elem and hdoc -> not used
>    return -> could be removed, method returns void
>    
>    loadElementDataIntoBuffer(Element elem, StringBuilder buffer) method
>    value != null -> name can't be null at this point
>    
>    getInputElementData(AttributeSet attr) method
>    value = null -> Already set at null
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/69e664de...9b423808

I'll take a look at the updated code as soon as I can. Sorry for such a long delay.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-3127080066

From duke at openjdk.org  Mon Jul 28 13:18:07 2025
From: duke at openjdk.org (Christian Heilmann)
Date: Mon, 28 Jul 2025 13:18:07 GMT
Subject: RFR: 8297191: [macos] printing page range "page 2 to 2" or
 "page 2 to 4" on macOS leads to not print [v2]
In-Reply-To: <VVHXcyKigp91z1dFVT4CHjSdTDDg0GuwrReuTY9XcwM=.1e316206-9bd1-4072-93d0-508d75e4435f@github.com>
References: <WP11pp2NaEWG1KMYtmz_1AIDmFvjbHWB87Qa6cClgas=.c5602f86-14f5-4488-8223-32e6e5ee202a@github.com>
 <gzn3rRhaqvWJd7Pdo2R0En2YMwaeFZIcO6skqlY1bBs=.76928e2c-3707-4271-8ee8-8a62da7224a6@github.com>
 <VVHXcyKigp91z1dFVT4CHjSdTDDg0GuwrReuTY9XcwM=.1e316206-9bd1-4072-93d0-508d75e4435f@github.com>
Message-ID: <J9NcIDYIi07U2HF2_59uf5Z7j4QHVag_9WUEhxY-no4=.0ea6fa5d-b2ec-4c56-a8e2-5b9e7e9187a8@github.com>

On Fri, 25 Jul 2025 21:16:38 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Christian Heilmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into pr/11266
>>  - Merge branch 'master' into pr/11266
>>  - 8297191 fixed printing page range for e.g. page 2 to 2 on macOS
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m line 149:
> 
>> 147:     else
>> 148:     {
>> 149:         aRange->length = fTotalPages;
> 
> But why didn't the old code work? If a range is set to 2-3, we know exactly the number of pages to print, and this number is 2.
> 
> Does it work correctly if `mDocument.getNumberOfPages()` in `CPrinterJob.java` returns a certain number instead of `UNKNOWN_NUMBER_OF_PAGES`?

> However, the fix resets the known range of pages to the full range of the document. Is it because the native code doesn't care about the range and it's handled in Java side?

It looks like the operating system does not expect the page range selected by the user here, but the number of pages in the document, even though it is queried as page range.


> Wouldn't it be easier then to always return NO from knowsPageRange? The fTotalPages field can be dropped from the PrinterView class.

Here we can only guess what exactly the operating system is doing in this case. For example, if the number of pages is not known, e.g. in streaming mode, the operating system must start with the first page and iterate through the pages until it reaches the desired page.
So I would let the operating system know the number of pages. It may help it to choose a more appropriate printing strategy.


> But why didn't the old code work? If a range is set to 2-3, we know exactly the number of pages to print, and this number is 2.

To answer this question, we need to look at the code of the operating system. But it seems that the operating system needs the total number of pages here, not the range selected by the user.
The documentation page does not describe it in detail either.

> Does it work correctly if mDocument.getNumberOfPages() in CPrinterJob.java returns a certain number instead of UNKNOWN_NUMBER_OF_PAGES?

I tried both variants and it does not work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11266#discussion_r2236415962

From achung at openjdk.org  Mon Jul 28 16:47:24 2025
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 28 Jul 2025 16:47:24 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v26]
In-Reply-To: <75YbhzZuU7f-pA0i8GgK2iCBF8bJP1GKtntdLbc6qEQ=.0330ef89-8dc7-46b3-92fa-f447ed2470b4@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <qIXtdwoE92RIVk99JaQhjWOiFmeq9omI-wSYA67g95s=.a92dd45e-84da-42a5-beb1-da75ee7c33f1@github.com>
 <75YbhzZuU7f-pA0i8GgK2iCBF8bJP1GKtntdLbc6qEQ=.0330ef89-8dc7-46b3-92fa-f447ed2470b4@github.com>
Message-ID: <icqYuKPNmO0iY-acJW2YaeXCOPZ8VEgfG54_BPxx-H4=.c5b8cb54-d3ac-46ac-8fbb-7b4811506e41@github.com>

On Fri, 25 Jul 2025 18:07:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove static from step delay/length fields
>
> test/jdk/lib/client/ExtendedRobot.java line 253:
> 
>> 251:      * @see     #delay(int)
>> 252:      */
>> 253:      public void glide(int srcX, int srcY, int destX, int destY, int stepLength, int speed) {
> 
> I hadn't noticed that this over-ride is both removed here and not added to Robot.
> If this were available, then perhaps those setters and getters for the current values aren't needed !
> What was the reason for not including it ? No one ever used it or something else ?

I actually removed this when I added the setters/getters since I thought it was redundant. Do you think having this override is better than having the setters/getters? I can revert the change

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2237236118

From prr at openjdk.org  Mon Jul 28 17:05:17 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Jul 2025 17:05:17 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v26]
In-Reply-To: <icqYuKPNmO0iY-acJW2YaeXCOPZ8VEgfG54_BPxx-H4=.c5b8cb54-d3ac-46ac-8fbb-7b4811506e41@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
 <qIXtdwoE92RIVk99JaQhjWOiFmeq9omI-wSYA67g95s=.a92dd45e-84da-42a5-beb1-da75ee7c33f1@github.com>
 <75YbhzZuU7f-pA0i8GgK2iCBF8bJP1GKtntdLbc6qEQ=.0330ef89-8dc7-46b3-92fa-f447ed2470b4@github.com>
 <icqYuKPNmO0iY-acJW2YaeXCOPZ8VEgfG54_BPxx-H4=.c5b8cb54-d3ac-46ac-8fbb-7b4811506e41@github.com>
Message-ID: <kF3UcBkGG_NM0a2HwG58nZefVZMLzbyoNwp7bMrF-74=.b49180ba-e5e0-4515-b631-7b350a0b7428@github.com>

On Mon, 28 Jul 2025 16:43:51 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test/jdk/lib/client/ExtendedRobot.java line 253:
>> 
>>> 251:      * @see     #delay(int)
>>> 252:      */
>>> 253:      public void glide(int srcX, int srcY, int destX, int destY, int stepLength, int speed) {
>> 
>> I hadn't noticed that this over-ride is both removed here and not added to Robot.
>> If this were available, then perhaps those setters and getters for the current values aren't needed !
>> What was the reason for not including it ? No one ever used it or something else ?
>
> I actually removed this when I added the setters/getters since I thought it was redundant. Do you think having this override is better than having the setters/getters? I can revert the change

Sorry for the churn, but yes I do think revert to the override

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22044#discussion_r2237291831

From aivanov at openjdk.org  Mon Jul 28 17:09:03 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 17:09:03 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v5]
In-Reply-To: <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>
Message-ID: <d5iDH2rZ7tR9loJdupKMWUiV8wC94zcPkaI0GsZQqNo=.78d9454f-b686-43de-9548-300efb5a8723@github.com>

On Fri, 25 Jul 2025 07:31:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use setVisible(false) instead of dispose, update test

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 129:

> 127:     transient  Frame frame;
> 128:     private    int desiredLocationX,desiredLocationY;
> 129:     transient private PropertyChangeListener propListener =

Suggestion:

    private transient PropertyChangeListener propListener =

Use blessed modifier order.

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 129:

> 127:     transient  Frame frame;
> 128:     private    int desiredLocationX,desiredLocationY;
> 129:     transient private PropertyChangeListener propListener =

I also suggest adding a blank line between location fields and `propListener`

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 142:

> 140:                 }
> 141:             }
> 142:         };

Anonymous class can be replaced with lambda?:
Suggestion:

            (e) -> {
                if (e.getOldValue() != null
                    && e.getNewValue() == null
                    && isVisible()) {
                    setVisible(false);
                }
            };

If you use the named property listener, checking the name of the property can be safely dropped, and the nested `if` blocks could be chained with the `&&` operator.

? @DamonGuy [advocated using lambdas in such cases](https://github.com/openjdk/jdk/pull/22977#discussion_r1909302224).

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 965:

> 963:                 oldInvoker.removePropertyChangeListener(oldPropListener);
> 964:             }
> 965:             invoker.addPropertyChangeListener(propListener);

Suggestion:


        if ((oldInvoker != this.invoker) && (ui != null)) {
            ui.uninstallUI(this);
            if (oldInvoker != null) {
                oldInvoker.removePropertyChangeListener(propListener);
            }
            invoker.addPropertyChangeListener(propListener);

`oldPropListener` is not needed, the instance never changes.

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 965:

> 963:                 oldInvoker.removePropertyChangeListener(oldPropListener);
> 964:             }
> 965:             invoker.addPropertyChangeListener(propListener);

Suggestion:

            if (oldInvoker != null) {
                oldInvoker.removePropertyChangeListener("ancestor", oldPropListener);
            }
            invoker.addPropertyChangeListener("ancestor", propListener);

Use named property listener, it's more efficient since the listener won't be called for any other properties.

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1429:

> 1427:         }
> 1428:         if(indexCounter < maxCounter && values.elementAt(indexCounter).
> 1429:                 equals("propListener")) {

Suggestion:

        if(indexCounter < maxCounter && values.elementAt(indexCounter).
           equals("propListener")) {

To align with the code above, wrapped `equals` has to use four-space indentation.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3056144669
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2231578655
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2237281954
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2237270173
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2231584604
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2237241406
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2237237614

From aivanov at openjdk.org  Mon Jul 28 17:14:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 17:14:59 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v5]
In-Reply-To: <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>
Message-ID: <DQuaw_Ai-PJr1Fy3gWuuFSv4gLHD47c2SH2gJ9aW1aA=.73b48601-28ad-4546-bb63-4bc871020769@github.com>

On Fri, 25 Jul 2025 07:31:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use setVisible(false) instead of dispose, update test

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1383:

> 1381:             values.addElement("propListener");
> 1382:             values.addElement(propListener);
> 1383:         }

Do we need to serialise `propListener`? What is the value in serialising the listener?

Will `invoker` serialise `propListener`? If it does, then we need to serialise it to be able to remove the listener after the components are deserialised and the `invoker` is changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2237320973

From aivanov at openjdk.org  Mon Jul 28 18:55:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 18:55:55 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v5]
In-Reply-To: <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>
Message-ID: <0mVsNPlameuWFzNV-P6nDgeKb5GguaZUPoIu0WX7NNg=.3421c72d-1b42-4363-a09f-d0a27922ef15@github.com>

On Fri, 25 Jul 2025 07:31:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use setVisible(false) instead of dispose, update test

I still think [using events and latches](https://github.com/openjdk/jdk/pull/26407#discussion_r2219783806) would be better.

> Perhaps, a better version of the test would remove the component when the event from the popup menu that it's now displayed is received. If the popup is hidden as the result of component removal, another event should be received. Thus, the test would depend on the events and latches instead of on the delays.

Thus, I suggest this version of the test: [`TestPopupInvoker.java`](https://github.com/openjdk/jdk/blob/63a511ae18ac145233bb9aa976f77b7d0c607ea3/test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java).

It is this version of the test that help me find [the bug in the implementation](https://github.com/openjdk/jdk/pull/26407#discussion_r2229306411) where hiding the popup menu didn't send events. Therefore, this version is more valuable: *it ensures the correct popup menu events are sent* when the invoker is removed and, as the result, the popup gets dismissed.

The [diff the most recent version](https://github.com/openjdk/jdk/commit/63a511ae18ac145233bb9aa976f77b7d0c607ea3) in this PR.

The updated version of the test is quicker, a loop of 10 iterations takes about 1 minute vs 1:11, that is around 10 seconds faster, which means each iteration completes around 1 second quicker.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3128559326

From aivanov at openjdk.org  Mon Jul 28 18:59:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 18:59:58 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v12]
In-Reply-To: <K6XplxZ0jffXV-19bVu3Zuy7scj6tfOUnyI60Oeh7FI=.e4d8df92-99c2-455d-849f-0ab59fd6c0a8@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <OR6xlEp9MMk9z2zuKKkP64Q-17HMPHYhfBKdaDKF2VQ=.06b831ce-8ec8-4f90-9c7c-3aedc5d89aa2@github.com>
 <i4BPuNcD8H3kyeVPAeAPaCvsBJbdG9NxVxVrzvfC58M=.78e4c633-fe9f-44f4-aea9-18483e532b1c@github.com>
 <v90zuPcY6O_xsW3sPIyQpM7PXrvQyRxae3NygbwspuA=.47b79d5c-1461-47ff-a9c1-f107b6d415ce@github.com>
 <K6XplxZ0jffXV-19bVu3Zuy7scj6tfOUnyI60Oeh7FI=.e4d8df92-99c2-455d-849f-0ab59fd6c0a8@github.com>
Message-ID: <TvGk_EU4GcsiYz_5i4PkkJHw7jQgyhlgA1Vyy9qfGRk=.625f53e0-daa8-452c-be6d-07f3176dd5ce@github.com>

On Fri, 11 Jul 2025 18:50:45 GMT, Phil Race <prr at openjdk.org> wrote:

>>> I think we need to have the "whole picture" tested to make sure everything does as we expect. It isn't so easy to tell even from looking at the source of ImageIcon. Then spec'ed so developers know what to expect. When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images Toolkit images are installed, even if they can't be used because the source isn't valid. They are "effectively" null, but not "actually" null. We should at least specify the null arg behaviours and try to say something about invalid image data. And as a result, I am now flipping to just documenting the setImage(null) NPE The protected method loadImage probably needs to say it too. Invalid image data, maybe we can cover that in a class level statement. Note: I'd like to see every constructor tested with both null and invalid image data.
>> 
>> I tested with null image/imagedata and invalid imagedata and it seems only these constructors throw NPE (current JDK) for null image (invalid image doesnt throw any exception)
>> 
>> ImageIcon(image, desc)
>> ImageIcon(image)
>> ImageIcon(byte[], desc)
>> ImageIcon(byte[])
>> 
>> Current PR checks for null in ImageIcon(image) so it will not throw NPE but ImageIcon(byte[]) will still throw..
>> Should we handle those in separate PR and let this only be for setImage(null)?
>
>> > I think we need to have the "whole picture" tested to make sure everything does as we expect. It isn't so easy to tell even from looking at the source of ImageIcon. Then spec'ed so developers know what to expect. When I wrote a little test, I see null args do generate NPEs but invalid args don't result in null images Toolkit images are installed, even if they can't be used because the source isn't valid. They are "effectively" null, but not "actually" null. We should at least specify the null arg behaviours and try to say something about invalid image data. And as a result, I am now flipping to just documenting the setImage(null) NPE The protected method loadImage probably needs to say it too. Invalid image data, maybe we can cover that in a class level statement. Note: I'd like to see every constructor tested with both null and invalid image data.
>> 
>> I tested with null image/imagedata and invalid imagedata and it seems only these constructors throw NPE (current JDK) for null image (invalid image doesnt throw any exception)
>> 
>> ImageIcon(image, desc) ImageIcon(image) ImageIcon(byte[], desc) ImageIcon(byte[])
>> 
>> Current PR checks for null in ImageIcon(image) so it will not throw NPE but ImageIcon(byte[]) will still throw.. Should we handle those in separate PR and let this only be for setImage(null)?
> 
> You told me (off-line) that null URL also throws NPE and I see that too.
> 
> This class is a bit of a mess of accidental behaviours and scant documentation.
> 
> Let's document all the NPE behaviours and include a test that verifies it.
> 
> And invalid data like "new byte[0]" or null for a file name,  or pointing to something that isn't an image file, or an invalid URL .. etc .. results in an Image instance being present, but it will never be completed so can never be drawn.
> 
> I think we need a class level statement like
> "If the image source parameter to a constructor is non-null, but does not reference valid accessible image data, no exceptions will be thrown but the image will be 'effectively' null, as it will have no dimensions and never be drawn, and
> getImageLoadStatus() will report ERRORED" - you should verify that last part but I think it is right.
> 
> We probably should add the similar text on setImage().
> 
> We can also test the invalid image data cases too.

@prrace The scope of this fix has expanded far beyound `ImageIcon.setImage` and its handling of `null` parameter.

Should the JBS title as well as the CSR be updated with a more relevant subject?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3128601184

From aivanov at openjdk.org  Mon Jul 28 19:47:05 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 19:47:05 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v22]
In-Reply-To: <Rxw3OcdARanhPp5FcdO7c_uFlo8XmP_T3_R9uQ1vCn4=.b32ceafd-dcca-411b-bc8f-c8326729b079@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
 <Rxw3OcdARanhPp5FcdO7c_uFlo8XmP_T3_R9uQ1vCn4=.b32ceafd-dcca-411b-bc8f-c8326729b079@github.com>
Message-ID: <N8AujFS74_QFP33Zj0iYCNq-gEqxUkc-zh4lf3WNxps=.0d08bc64-9d96-4551-9be0-80e669e40bc3@github.com>

On Mon, 28 Jul 2025 19:13:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ArgType name change
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 186:
> 
>> 184:      * @param location the URL for the image
>> 185:      * @param description a brief textual description of the image
>> 186:      * @throws {@code NullPointerException} if (@code null) URL is passed.
> 
> Suggestion:
> 
>      * @throws NullPointerException if a {@code null} URL is passed
> 
> The exception type is automatically rendered in monospaced font with a link to its description.
> 
> You meant to use braces instead of parentheses.
> 
> Usually, there's no full stop for `@throws`.
> 
> Alternatively, specify the parameter name for more clarity:
> Suggestion:
> 
>      * @throws NullPointerException if {@code location} is {@code null}

Indeed, `@throws {@code NullPointerException}` is an invalid syntax ? the build fails.

?/src/java.desktop/share/classes/javax/swing/ImageIcon.java:186: error: unexpected text
     * @throws {@code NullPointerException} if (@code null) URL is passed.
               ^

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237672905

From aivanov at openjdk.org  Mon Jul 28 19:47:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 19:47:04 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v22]
In-Reply-To: <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
Message-ID: <Rxw3OcdARanhPp5FcdO7c_uFlo8XmP_T3_R9uQ1vCn4=.b32ceafd-dcca-411b-bc8f-c8326729b079@github.com>

On Sun, 27 Jul 2025 07:08:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ArgType name change

At what point did we decide not to modify `Image.setImage` to accept `null` as the parameter? It made perfect sense.

I wonder if it's possible to use JUnit a test framework in jtreg?

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 64:

> 62:  * are preloaded using MediaTracker to monitor the loaded state
> 63:  * of the image.
> 64:  * If the image source parameter to a constructor or method is non-null,

Suggestion:

 * of the image.
 *
 * <p>
 * If the image source parameter to a constructor or method is non-null,

I suggest putting the discussion on non-null parameters in its own paragraph for ease of reading the javadoc.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:

> 66:  * no exceptions will be thrown but the image will be unset,
> 67:  * as it will have no dimensions and never be drawn, and
> 68:  * {@code getImageLoadStatus()} will report {@see java.awt.MediaTracker#ERRORED}.

Suggestion:

 * {@code getImageLoadStatus()} will report {@link java.awt.MediaTracker#ERRORED}.

You shouldn't use `@see` here, it should either be `@code` or `@link`. I think both references should use the same tag: either `@code` or `@link`; the latter allows quickly navigating to the *method* or constant.

Perhaps, `@link` for the `getImageLoadStatus` method would work better: it allows viewing the description of the method and its purpose; in its turn, `getImageLoadStatus` references possible return values including `MediaTracker.ERRORED` with `@see` tag.

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 186:

> 184:      * @param location the URL for the image
> 185:      * @param description a brief textual description of the image
> 186:      * @throws {@code NullPointerException} if (@code null) URL is passed.

Suggestion:

     * @throws NullPointerException if a {@code null} URL is passed

The exception type is automatically rendered in monospaced font with a link to its description.

You meant to use braces instead of parentheses.

Usually, there's no full stop for `@throws`.

Alternatively, specify the parameter name for more clarity:
Suggestion:

     * @throws NullPointerException if {@code location} is {@code null}

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 206:

> 204:      * a string representation of the URL.
> 205:      * @param location the URL for the image
> 206:      * @throws {@code NullPointerException} if (@code null) URL is passed.

Suggestion:

     * @throws NullPointerException if a {@code null} URL is passed

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 217:

> 215:      * @param image the image
> 216:      * @param description a brief textual description of the image
> 217:      * @throws {@code NullPointerException} if (@code null) Image is passed.

Suggestion:

     * @throws NullPointerException if a {@code null} image is passed

Here, image shouldn't be capitalised, you mean it as the literal _?image?_ rather than a type.

I still prefer specifying the parameter name:
Suggestion:

     * @throws NullPointerException if {@code image} is {@code null}

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 229:

> 227:      * then the string is used as the description of this icon.
> 228:      * @param image the image
> 229:      * @throws {@code NullPointerException} if (@code null) Image is passed.

Suggestion:

     * @throws NullPointerException if {@code image} is {@code null}

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 253:

> 251:      *         by the AWT Toolkit, such as GIF, JPEG, or (as of 1.3) PNG
> 252:      * @param  description a brief textual description of the image
> 253:      * @throws {@code NullPointerException} if (@code null) imageData is passed.

Suggestion:

     * @throws NullPointerException if {@code imageData} is {@code null}

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 277:

> 275:      * @param  imageData an array of pixels in an image format supported by
> 276:      *             the AWT Toolkit, such as GIF, JPEG, or (as of 1.3) PNG
> 277:      * @throws {@code NullPointerException} if (@code null) imageData is passed.

Suggestion:

     * @throws NullPointerException if {@code imageData} is {@code null}

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 382:

> 380:      * Sets the image displayed by this icon.
> 381:      * @param image the image
> 382:      * @throws {@code NullPointerException} if (@code null) Image is passed.

Suggestion:

     * @throws NullPointerException if {@code image} is {@code null}

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 39:

> 37: import javax.swing.ImageIcon;
> 38: 
> 39: public class ImageIconTest {

Suggestion:

public class ImageIconNullParametersTest {

Be more specific?

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 52:

> 50:             fos.write(invalidData);
> 51:         }
> 52:         String fileName = (new File(System.getProperty("test.src", "."), imgName)).getName();

Why do we need jumping over the hoops?

You're creating an image, put it into the current directory that defaults to `scratch` directory in jtreg. The `scratch` directory is automatically cleaned by jtreg between tests, thus you won't even leave files in the source tree of JDK.

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 66:

> 64:                            new ImageIcon(s);
> 65:                            passed = true; // no exception expected for this case
> 66:                            break;

Does it make sense to create richer enum values which combine the expected state?

-------------

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-3064243188
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237595098
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237623088
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237628892
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237634552
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237651047
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237652775
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237657503
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237660636
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237662773
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237696278
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237685414
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237693876

From aivanov at openjdk.org  Mon Jul 28 20:05:03 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 20:05:03 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v19]
In-Reply-To: <kG-4XQ5nG8yu8Dm-k8qfhIKzJCI2eD2RmwxorNFh0Ho=.e5b35d46-467b-441b-9258-a9b8abeb8d4c@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <BOZ10DOvvVfoIcmEzTmrOrsud9KnsIckOtc2pu_s_-E=.8729cdab-84c9-4187-a564-e118ff2d79be@github.com>
 <QZOXeyT-DuTzxVklugCzUqhzasytjfVa0kKBdJDLDxs=.c6b85d96-9e78-4a90-828a-563a22566ac5@github.com>
 <kG-4XQ5nG8yu8Dm-k8qfhIKzJCI2eD2RmwxorNFh0Ho=.e5b35d46-467b-441b-9258-a9b8abeb8d4c@github.com>
Message-ID: <c5oAA8wAeNMP5vJ7Ve_j_vqnVEULn0ehK0H-Q8NnT2c=.206f1481-38ec-43b6-81fd-ab6b7e3d5833@github.com>

On Sun, 27 Jul 2025 06:57:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 66:
>> 
>>> 64:  * If the image source parameter to a constructor or method is non-null,
>>> 65:  * but does not reference valid accessible image data,
>>> 66:  * no exceptions will be thrown but the image will be 'effectively' null,
>> 
>> Joe asked for if there's an alternative to 'effectively' null. I'm open to suggestions. "unset" ?
>
> "unset" sounded better..modified..

_?unset?_ is also not ideal, it's not clear what it means, especially for constructors where the image isn't set yet.

If I get it right, it refers to the fact that the image in `ImageIcon` instance is non-null, but nothing gets rendered because there's no valid image.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237748355

From aivanov at openjdk.org  Mon Jul 28 20:12:01 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 20:12:01 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v22]
In-Reply-To: <Rxw3OcdARanhPp5FcdO7c_uFlo8XmP_T3_R9uQ1vCn4=.b32ceafd-dcca-411b-bc8f-c8326729b079@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
 <Rxw3OcdARanhPp5FcdO7c_uFlo8XmP_T3_R9uQ1vCn4=.b32ceafd-dcca-411b-bc8f-c8326729b079@github.com>
Message-ID: <dysRne4pHhIqKNGpE1tq3aT0hZc_ftBPWOC3Nc74vxw=.cc3b4868-50dd-41a9-960a-a1589fef093a@github.com>

On Mon, 28 Jul 2025 19:11:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ArgType name change
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:
> 
>> 66:  * no exceptions will be thrown but the image will be unset,
>> 67:  * as it will have no dimensions and never be drawn, and
>> 68:  * {@code getImageLoadStatus()} will report {@see java.awt.MediaTracker#ERRORED}.
> 
> Suggestion:
> 
>  * {@code getImageLoadStatus()} will report {@link java.awt.MediaTracker#ERRORED}.
> 
> You shouldn't use `@see` here, it should either be `@code` or `@link`. I think both references should use the same tag: either `@code` or `@link`; the latter allows quickly navigating to the *method* or constant.
> 
> Perhaps, `@link` for the `getImageLoadStatus` method would work better: it allows viewing the description of the method and its purpose; in its turn, `getImageLoadStatus` references possible return values including `MediaTracker.ERRORED` with `@see` tag.

Indeed, this is not supported, the generated javadoc looks like this:

??and `getImageLoadStatus()` will report .?

Therefore I suggest the following:


 * {@link #getImageLoadStatus()} will report {@code MediaTracker.ERRORED}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2237763884

From aivanov at openjdk.org  Mon Jul 28 20:55:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 20:55:58 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v22]
In-Reply-To: <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
Message-ID: <KkdTokUX6aVRfp1lEBHMUoYy4_rpJ-hd0vv_47c4iU0=.db9cf129-877d-4433-b4e4-645bdb67a639@github.com>

On Sun, 27 Jul 2025 07:08:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ArgType name change

Currently, [JDK-8159055](https://bugs.openjdk.org/browse/JDK-8159055) is an enhancement which made sense while the goal of this PR was to change `Image.setImage` so that it accepts `null` as parameter.

After a month of discussions, that solution has been abandoned, instead it is stated that `Image.setImage` will throw `NullPointerException` if `image` parameter is `null`.

I think the type of JDK-8159055 should be changed to *bug*.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3129858458

From aivanov at openjdk.org  Mon Jul 28 21:53:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 28 Jul 2025 21:53:59 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v22]
In-Reply-To: <KkdTokUX6aVRfp1lEBHMUoYy4_rpJ-hd0vv_47c4iU0=.db9cf129-877d-4433-b4e4-645bdb67a639@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
 <KkdTokUX6aVRfp1lEBHMUoYy4_rpJ-hd0vv_47c4iU0=.db9cf129-877d-4433-b4e4-645bdb67a639@github.com>
Message-ID: <7BaOt1DwCTyzw73ErYlBMtkBuDIrVJeh96losTusZQk=.1a813e75-0744-49c1-aabc-bb434236b141@github.com>

On Mon, 28 Jul 2025 20:53:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Currently, [JDK-8159055](https://bugs.openjdk.org/browse/JDK-8159055) is an enhancement which made sense while the goal of this PR was to change `Image.setImage` so that it accepts `null` as parameter.
> 
> After a month of discussions, that solution has been abandoned, instead it is stated that `Image.setImage` will throw `NullPointerException` if `image` parameter is `null`.

I think the proposed fix to accept `null` for `Image.setImage` should've been accepted, specifically https://github.com/openjdk/jdk/compare/master...340254ecceab48f5a0037b32e477a0e168ab2779

Then for documenting handling `null` and invalid parameters, a new bug should've been created, as per [this discussion](https://github.com/openjdk/jdk/pull/25767#issuecomment-3063379284):

> This class is a bit of a mess of accidental behaviours and scant documentation.
>
> Let's document all the NPE behaviours and include a test that verifies it.
> 
> And invalid data like "new byte[0]" or null for a file name, or pointing to something that isn't an image file, or an invalid URL .. etc .. results in an Image instance being present, but it will never be completed so can never be drawn.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3129978878

From prr at openjdk.org  Mon Jul 28 23:11:48 2025
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Jul 2025 23:11:48 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away from
 using finalize
Message-ID: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>

Convert StringContent's Position usage tracking to use a WeakReference

The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

-------------

Commit messages:
 - 8364230

Changes: https://git.openjdk.org/jdk/pull/26519/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26519&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364230
  Stats: 92 lines in 2 files changed: 71 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/26519.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26519/head:pull/26519

PR: https://git.openjdk.org/jdk/pull/26519

From jdv at openjdk.org  Tue Jul 29 05:44:05 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 29 Jul 2025 05:44:05 GMT
Subject: RFR: 8364135: JPEGImageReader.getImageTypes() should throw exception
 for non-zero image index
Message-ID: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>

We need to throw appropriate exception when we pass invalid image index values to ImageReader.getImageTypes().
We throw IOOBE in all other plugins except JPEG, Added appropriate check to throw IOOBE when JpegImageReader has invalid image index.

-------------

Commit messages:
 - 8364135: JPEGImageReader.getImageTypes() should throw exception for non-zero image index

Changes: https://git.openjdk.org/jdk/pull/26522/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26522&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364135
  Stats: 67 lines in 2 files changed: 67 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26522/head:pull/26522

PR: https://git.openjdk.org/jdk/pull/26522

From smandalika at openjdk.org  Tue Jul 29 05:58:00 2025
From: smandalika at openjdk.org (Srinivas Mandalika)
Date: Tue, 29 Jul 2025 05:58:00 GMT
Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java
In-Reply-To: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>
References: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>
Message-ID: <oAhV8ayV4cW2G5fNjykp_ConiQPl2xdthi58L4KS3JY=.22a8688e-2040-4db3-8d77-fc1e4558274d@github.com>

On Fri, 25 Jul 2025 05:33:31 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> The java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java test uses object monitors and wait/notify to synchronise actions in the test.
> 
> Using CountDownLatch could make the test simpler, shorter, clearer.
> Tested the code on a windows-x64, macos-x64 and lnux-x64 machines and the test is working as expected.

Can someone take a quick look and provide feedback on this simple refactoring change ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26471#issuecomment-3130801539

From myankelevich at openjdk.org  Tue Jul 29 10:40:56 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Tue, 29 Jul 2025 10:40:56 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize
In-Reply-To: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
Message-ID: <z23-G9qDrahHOzP_o7zCs-mruhQZPlU6ckmrVmd-270=.d0ae5406-d3a2-482b-be74-2b4138f9bef8@github.com>

On Mon, 28 Jul 2025 22:38:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Convert StringContent's Position usage tracking to use a WeakReference
> 
> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

Could you please upfat

src/java.desktop/share/classes/javax/swing/text/StringContent.java line 27:

> 25: package javax.swing.text;
> 26: 
> 27: import java.util.Vector;

Could you please update copyright in this file?

test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 29:

> 27: 
> 28: /*
> 29:  * @test

Could you please add `@bug` with bug id here

-------------

PR Review: https://git.openjdk.org/jdk/pull/26519#pullrequestreview-3066804830
PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2239345313
PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2239349764

From psadhukhan at openjdk.org  Tue Jul 29 11:56:49 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 11:56:49 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v6]
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use named property listener, update test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26407/files
  - new: https://git.openjdk.org/jdk/pull/26407/files/c5da4598..8af3c94d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26407&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26407&range=04-05

  Stats: 65 lines in 2 files changed: 29 ins; 12 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/26407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26407/head:pull/26407

PR: https://git.openjdk.org/jdk/pull/26407

From psadhukhan at openjdk.org  Tue Jul 29 11:56:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 11:56:53 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed.
 [v5]
In-Reply-To: <d5iDH2rZ7tR9loJdupKMWUiV8wC94zcPkaI0GsZQqNo=.78d9454f-b686-43de-9548-300efb5a8723@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>
 <d5iDH2rZ7tR9loJdupKMWUiV8wC94zcPkaI0GsZQqNo=.78d9454f-b686-43de-9548-300efb5a8723@github.com>
Message-ID: <tt0d1D_PpyCTqt2L62wV9TdbyjY4W4r0oWd-nl-oXy8=.e0e0bba4-e6d2-4492-88fc-9cd10781da4b@github.com>

On Fri, 25 Jul 2025 16:37:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use setVisible(false) instead of dispose, update test
>
> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 129:
> 
>> 127:     transient  Frame frame;
>> 128:     private    int desiredLocationX,desiredLocationY;
>> 129:     transient private PropertyChangeListener propListener =
> 
> Suggestion:
> 
>     private transient PropertyChangeListener propListener =
> 
> Use blessed modifier order.

ok

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 142:
> 
>> 140:                 }
>> 141:             }
>> 142:         };
> 
> Anonymous class can be replaced with lambda?:
> Suggestion:
> 
>             (e) -> {
>                 if (e.getOldValue() != null
>                     && e.getNewValue() == null
>                     && isVisible()) {
>                     setVisible(false);
>                 }
>             };
> 
> If you use the named property listener, checking the name of the property can be safely dropped, and the nested `if` blocks could be chained with the `&&` operator.
> 
> ? @DamonGuy [advocated using lambdas in such cases](https://github.com/openjdk/jdk/pull/22977#discussion_r1909302224).

ok..modified..

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 965:
> 
>> 963:                 oldInvoker.removePropertyChangeListener(oldPropListener);
>> 964:             }
>> 965:             invoker.addPropertyChangeListener(propListener);
> 
> Suggestion:
> 
> 
>         if ((oldInvoker != this.invoker) && (ui != null)) {
>             ui.uninstallUI(this);
>             if (oldInvoker != null) {
>                 oldInvoker.removePropertyChangeListener(propListener);
>             }
>             invoker.addPropertyChangeListener(propListener);
> 
> `oldPropListener` is not needed, the instance never changes.

fixed..

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 965:
> 
>> 963:                 oldInvoker.removePropertyChangeListener(oldPropListener);
>> 964:             }
>> 965:             invoker.addPropertyChangeListener(propListener);
> 
> Suggestion:
> 
>             if (oldInvoker != null) {
>                 oldInvoker.removePropertyChangeListener("ancestor", oldPropListener);
>             }
>             invoker.addPropertyChangeListener("ancestor", propListener);
> 
> Use named property listener, it's more efficient since the listener won't be called for any other properties.

ok

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1383:
> 
>> 1381:             values.addElement("propListener");
>> 1382:             values.addElement(propListener);
>> 1383:         }
> 
> Do we need to serialise `propListener`? What is the value in serialising the listener?
> 
> Will `invoker` serialise `propListener`? If it does, then we need to serialise it to be able to remove the listener after the components are deserialised and the `invoker` is changed.

There was failure in CI in some test citing NotSerializableException which was solved by serialising propListener

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239551917
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239553307
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239552668
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239552914
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239556446

From aivanov at openjdk.org  Tue Jul 29 12:03:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 12:03:59 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
Message-ID: <e4SP7FJJdj8tBnVl0Mh8VFn02FCCkMmU8y_qYCXUsB4=.370858b6-b413-4ff4-9f8d-2f43c3528f1a@github.com>

On Tue, 29 Jul 2025 11:56:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use named property listener, update test

Looks good to me.

May I be recorded as a contributor / co-author for the test?

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3067165449
PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3132156615

From aturbanov at openjdk.org  Tue Jul 29 12:08:57 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 29 Jul 2025 12:08:57 GMT
Subject: RFR: 8364230: javax/swing/text/StringContent can be migrated away
 from using finalize
In-Reply-To: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
References: <2WIWvTGPNsBVXib1Y2M8mSJgs8jOkiIUVDwyB7oVwrA=.773ac17f-b27b-4d42-a1bb-2b37df49fafc@github.com>
Message-ID: <A4JyvGe3XoZcaMuhc9a4291bFUTPHIcl6H4nx87ikgE=.b1d344e7-36af-479f-8f6c-af01bdff2b11@github.com>

On Mon, 28 Jul 2025 22:38:03 GMT, Phil Race <prr at openjdk.org> wrote:

> Convert StringContent's Position usage tracking to use a WeakReference
> 
> The test that is added only implicitly tests this but I added it because of a complete lack of any test for this code.

test/jdk/javax/swing/text/AbstractDocument/StringContentPositionTest.java line 62:

> 60:            }
> 61:         }
> 62:         st.remove(0,  SIZE * LEN);

Suggestion:

        st.remove(0, SIZE * LEN);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26519#discussion_r2239589762

From aivanov at openjdk.org  Tue Jul 29 12:10:04 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 12:10:04 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
Message-ID: <aJrEbBf1NzGuHedfjWmCkDYMtXmiFc1facjNaItt9JY=.fd019f54-cae9-4889-b946-aaeccf05ee5e@github.com>

On Tue, 29 Jul 2025 11:56:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use named property listener, update test

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 136:

> 134:                     && isVisible()) {
> 135:                     setVisible(false);
> 136:                 }

Should we hide the popup if invoker changes to another value?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239583879

From aivanov at openjdk.org  Tue Jul 29 12:10:05 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 12:10:05 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v5]
In-Reply-To: <tt0d1D_PpyCTqt2L62wV9TdbyjY4W4r0oWd-nl-oXy8=.e0e0bba4-e6d2-4492-88fc-9cd10781da4b@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <Pvm_oEUs4lq4xP4gZpMhuMuKi27yYWLJv1EWYitmrmA=.3245234c-9e6d-4590-88ec-a9bd2ebbd76c@github.com>
 <d5iDH2rZ7tR9loJdupKMWUiV8wC94zcPkaI0GsZQqNo=.78d9454f-b686-43de-9548-300efb5a8723@github.com>
 <tt0d1D_PpyCTqt2L62wV9TdbyjY4W4r0oWd-nl-oXy8=.e0e0bba4-e6d2-4492-88fc-9cd10781da4b@github.com>
Message-ID: <chCp6qHW9BcwSNhZayqjC5NqMTbfuMVI0wfHAn0SFO8=.bf5622e4-6721-45aa-882e-55256d493761@github.com>

On Tue, 29 Jul 2025 11:53:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1383:
>> 
>>> 1381:             values.addElement("propListener");
>>> 1382:             values.addElement(propListener);
>>> 1383:         }
>> 
>> Do we need to serialise `propListener`? What is the value in serialising the listener?
>> 
>> Will `invoker` serialise `propListener`? If it does, then we need to serialise it to be able to remove the listener after the components are deserialised and the `invoker` is changed.
>
> There was failure in CI in some test citing NotSerializableException which was solved by serialising propListener

Weird? transient fields aren't serialised.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239590058

From aturbanov at openjdk.org  Tue Jul 29 12:14:03 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 29 Jul 2025 12:14:03 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v2]
In-Reply-To: <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
Message-ID: <U5IXVBLBrohzF3siWITFjykdL5nakfYWt0jyNkQmfWI=.7301007d-113a-4b2f-85b0-2373a6717104@github.com>

On Tue, 22 Jul 2025 22:10:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> As laid out in the JBS issue, this updates the java.awt.PrintJob implementation to use a delegate which can be disposed instead of relying on finalize().
>> 
>> PrintJob.finalize() is not being removed, and won't be removed until there is a more definite plan for completely removing the finalize() mechanism.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8363889

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 123:

> 121:         MediaSizeName.ISO_A10, MediaSizeName.ISO_B0, MediaSizeName.ISO_B1,
> 122:         MediaSizeName.ISO_B2, MediaSizeName.ISO_B3, MediaSizeName.ISO_B4,
> 123:         MediaSizeName.ISO_B5,  MediaSizeName.ISO_B6, MediaSizeName.ISO_B7,

Suggestion:

        MediaSizeName.ISO_B5, MediaSizeName.ISO_B6, MediaSizeName.ISO_B7,

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 293:

> 291:     private Thread printerJobThread;
> 292: 
> 293:     public PrintJobDelegate(Frame frame,  String doctitle,

Suggestion:

    public PrintJobDelegate(Frame frame, String doctitle,

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 303:

> 301:     }
> 302: 
> 303:     public PrintJobDelegate(Frame frame,  String doctitle,

Suggestion:

    public PrintJobDelegate(Frame frame, String doctitle,

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 309:

> 307:     }
> 308: 
> 309:     private void initPrintJob2D(Frame frame,  String doctitle,

Suggestion:

    private void initPrintJob2D(Frame frame, String doctitle,

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 387:

> 385:         DialogType d = this.jobAttributes.getDialog();
> 386:         PrintService pServ = printerJob.getPrintService();
> 387:         if ((pServ == null) &&  (d == DialogType.NONE)){

Suggestion:

        if ((pServ == null) && (d == DialogType.NONE)){

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 411:

> 409:             if (d == DialogType.NATIVE) {
> 410:                 attributes.add(DialogTypeSelection.NATIVE);
> 411:             }  else { //  (d == DialogType.COMMON)

Suggestion:

            } else { //  (d == DialogType.COMMON)

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 439:

> 437: 
> 438:             Media media = (Media)attributes.get(Media.class);
> 439:             MediaSize mediaSize =  null;

Suggestion:

            MediaSize mediaSize = null;

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 824:

> 822:              */
> 823:             //printGraphics = new ProxyPrintGraphics(currentGraphics.create(), this);
> 824:             printGraphics =  currentGraphics.create();

Suggestion:

            printGraphics = currentGraphics.create();

src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 906:

> 904:          * are released, files closed etc.
> 905:          */
> 906:         if( printerJobThread != null && printerJobThread.isAlive() ){

Suggestion:

        if (printerJobThread != null && printerJobThread.isAlive() ){

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239598578
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239599185
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239599562
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239599930
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239600419
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239601037
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239601366
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239602520
PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2239602907

From psadhukhan at openjdk.org  Tue Jul 29 12:20:57 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 12:20:57 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <e4SP7FJJdj8tBnVl0Mh8VFn02FCCkMmU8y_qYCXUsB4=.370858b6-b413-4ff4-9f8d-2f43c3528f1a@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <e4SP7FJJdj8tBnVl0Mh8VFn02FCCkMmU8y_qYCXUsB4=.370858b6-b413-4ff4-9f8d-2f43c3528f1a@github.com>
Message-ID: <Gd3KcEjG6J_wXMZgc4jEwPzlQkTLL4mIDTQSLGkdV_s=.c25c39eb-2d08-4119-907f-32818f76a078@github.com>

On Tue, 29 Jul 2025 12:01:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> May I be recorded as a contributor / co-author for the test?

Added

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 136:
> 
>> 134:                     && isVisible()) {
>> 135:                     setVisible(false);
>> 136:                 }
> 
> Should we hide the popup if invoker changes to another value?

Listener is added only when invoker is changed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3132210949
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239616868

From aivanov at openjdk.org  Tue Jul 29 12:20:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 12:20:58 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <Gd3KcEjG6J_wXMZgc4jEwPzlQkTLL4mIDTQSLGkdV_s=.c25c39eb-2d08-4119-907f-32818f76a078@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <e4SP7FJJdj8tBnVl0Mh8VFn02FCCkMmU8y_qYCXUsB4=.370858b6-b413-4ff4-9f8d-2f43c3528f1a@github.com>
 <Gd3KcEjG6J_wXMZgc4jEwPzlQkTLL4mIDTQSLGkdV_s=.c25c39eb-2d08-4119-907f-32818f76a078@github.com>
Message-ID: <WqQvHJxuyA1tflXiM0Njnyh5-eANMtDV9Y3HnNAa_mM=.f9d947e2-638b-4365-ac5c-25f8b7994b06@github.com>

On Tue, 29 Jul 2025 12:16:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 136:
>> 
>>> 134:                     && isVisible()) {
>>> 135:                     setVisible(false);
>>> 136:                 }
>> 
>> Should we hide the popup if invoker changes to another value?
>
> Listener is added only when invoker is changed

Yes, but we hide the popup only when `invoker` is changed to `null`. Should we hide the popup whenever `invoker` is changed to a different value?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239623745

From psadhukhan at openjdk.org  Tue Jul 29 12:26:55 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 12:26:55 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <WqQvHJxuyA1tflXiM0Njnyh5-eANMtDV9Y3HnNAa_mM=.f9d947e2-638b-4365-ac5c-25f8b7994b06@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <e4SP7FJJdj8tBnVl0Mh8VFn02FCCkMmU8y_qYCXUsB4=.370858b6-b413-4ff4-9f8d-2f43c3528f1a@github.com>
 <Gd3KcEjG6J_wXMZgc4jEwPzlQkTLL4mIDTQSLGkdV_s=.c25c39eb-2d08-4119-907f-32818f76a078@github.com>
 <WqQvHJxuyA1tflXiM0Njnyh5-eANMtDV9Y3HnNAa_mM=.f9d947e2-638b-4365-ac5c-25f8b7994b06@github.com>
Message-ID: <Zt45ImSs26gi9UzFf_DzMcCJbWoDKYQOGpLro3xW2cY=.ed859814-c6a6-4a74-a2b4-49ee6ff04b0a@github.com>

On Tue, 29 Jul 2025 12:18:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Listener is added only when invoker is changed
>
> Yes, but we hide the popup only when `invoker` is changed to `null`. Should we hide the popup whenever `invoker` is changed to a different value?

We hide the popup when `ancestor` is changed to `null`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239634212

From aivanov at openjdk.org  Tue Jul 29 12:26:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 12:26:55 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <Zt45ImSs26gi9UzFf_DzMcCJbWoDKYQOGpLro3xW2cY=.ed859814-c6a6-4a74-a2b4-49ee6ff04b0a@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <e4SP7FJJdj8tBnVl0Mh8VFn02FCCkMmU8y_qYCXUsB4=.370858b6-b413-4ff4-9f8d-2f43c3528f1a@github.com>
 <Gd3KcEjG6J_wXMZgc4jEwPzlQkTLL4mIDTQSLGkdV_s=.c25c39eb-2d08-4119-907f-32818f76a078@github.com>
 <WqQvHJxuyA1tflXiM0Njnyh5-eANMtDV9Y3HnNAa_mM=.f9d947e2-638b-4365-ac5c-25f8b7994b06@github.com>
 <Zt45ImSs26gi9UzFf_DzMcCJbWoDKYQOGpLro3xW2cY=.ed859814-c6a6-4a74-a2b4-49ee6ff04b0a@github.com>
Message-ID: <mLuk-u_4ntOlqFllGiS-8hwDNiLcVWzKMWjrm99qfKI=.b6f985c3-faca-46f7-932f-2dbcada62a82@github.com>

On Tue, 29 Jul 2025 12:21:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yes, but we hide the popup only when `invoker` is changed to `null`. Should we hide the popup whenever `invoker` is changed to a different value?
>
> We hide the popup when `ancestor` is changed to `null`

Yeah! You're right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2239640881

From psadhukhan at openjdk.org  Tue Jul 29 12:44:24 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 12:44:24 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v23]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <FlrPHhl3ZJGFczIog1baWeU2ws1UZCnQldPRY4jRadY=.89bf0864-dc3d-42bc-82ce-bab9c7631c45@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Rectify @throws clause, update test to delete file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/69708ca2..a31f51a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=21-22

  Stats: 13 lines in 2 files changed: 4 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/25767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767

PR: https://git.openjdk.org/jdk/pull/25767

From psadhukhan at openjdk.org  Tue Jul 29 12:44:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 12:44:25 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v22]
In-Reply-To: <Rxw3OcdARanhPp5FcdO7c_uFlo8XmP_T3_R9uQ1vCn4=.b32ceafd-dcca-411b-bc8f-c8326729b079@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
 <Rxw3OcdARanhPp5FcdO7c_uFlo8XmP_T3_R9uQ1vCn4=.b32ceafd-dcca-411b-bc8f-c8326729b079@github.com>
Message-ID: <Y2elgG7AquGjvp7CdXOqIaLeAAQYarOweUTjTTT5nNY=.fc9da64e-dcc1-4e4e-a096-63f5b1222cbe@github.com>

On Mon, 28 Jul 2025 19:00:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ArgType name change
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 64:
> 
>> 62:  * are preloaded using MediaTracker to monitor the loaded state
>> 63:  * of the image.
>> 64:  * If the image source parameter to a constructor or method is non-null,
> 
> Suggestion:
> 
>  * of the image.
>  *
>  * <p>
>  * If the image source parameter to a constructor or method is non-null,
> 
> I suggest putting the discussion on non-null parameters in its own paragraph for ease of reading the javadoc.

ok

> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 206:
> 
>> 204:      * a string representation of the URL.
>> 205:      * @param location the URL for the image
>> 206:      * @throws {@code NullPointerException} if (@code null) URL is passed.
> 
> Suggestion:
> 
>      * @throws NullPointerException if a {@code null} URL is passed

ok

> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 217:
> 
>> 215:      * @param image the image
>> 216:      * @param description a brief textual description of the image
>> 217:      * @throws {@code NullPointerException} if (@code null) Image is passed.
> 
> Suggestion:
> 
>      * @throws NullPointerException if a {@code null} image is passed
> 
> Here, _?image?_ shouldn't be capitalised, you mean it as the literal _?image?_ rather than a type.
> 
> I still prefer specifying the parameter name:
> Suggestion:
> 
>      * @throws NullPointerException if {@code image} is {@code null}

ok

> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 39:
> 
>> 37: import javax.swing.ImageIcon;
>> 38: 
>> 39: public class ImageIconTest {
> 
> Suggestion:
> 
> public class ImageIconNullParametersTest {
> 
> Be more specific?

it is not just testing for NullParameters

> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 52:
> 
>> 50:             fos.write(invalidData);
>> 51:         }
>> 52:         String fileName = (new File(System.getProperty("test.src", "."), imgName)).getName();
> 
> Why do we need jumping over the hoops?
> 
> You're creating an image, put it into the current directory that defaults to `scratch` directory in jtreg. The `scratch` directory is automatically cleaned by jtreg between tests, thus you won't even leave files in the source tree of JDK.

used file.deleteOnExit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2239691809
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2239693016
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2239693481
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2239695863
PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2239697154

From psadhukhan at openjdk.org  Tue Jul 29 12:44:25 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 12:44:25 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v22]
In-Reply-To: <dysRne4pHhIqKNGpE1tq3aT0hZc_ftBPWOC3Nc74vxw=.cc3b4868-50dd-41a9-960a-a1589fef093a@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <eajzjh8x1zEwPitfKqj-G3NMYsM5a04krH2eOjXyDyk=.d2f295ab-85a3-403f-8bec-a1c1cf74e459@github.com>
 <Rxw3OcdARanhPp5FcdO7c_uFlo8XmP_T3_R9uQ1vCn4=.b32ceafd-dcca-411b-bc8f-c8326729b079@github.com>
 <dysRne4pHhIqKNGpE1tq3aT0hZc_ftBPWOC3Nc74vxw=.cc3b4868-50dd-41a9-960a-a1589fef093a@github.com>
Message-ID: <rvTW30zxOlLQWqu47RIqJKZzoyVUmfKagPaIK8efkGg=.79290db6-9a01-4716-85ec-500a9a4c15f0@github.com>

On Mon, 28 Jul 2025 20:09:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:
>> 
>>> 66:  * no exceptions will be thrown but the image will be unset,
>>> 67:  * as it will have no dimensions and never be drawn, and
>>> 68:  * {@code getImageLoadStatus()} will report {@see java.awt.MediaTracker#ERRORED}.
>> 
>> Suggestion:
>> 
>>  * {@code getImageLoadStatus()} will report {@link java.awt.MediaTracker#ERRORED}.
>> 
>> You shouldn't use `@see` here, it should either be `@code` or `@link`. I think both references should use the same tag: either `@code` or `@link`; the latter allows quickly navigating to the *method* or constant.
>> 
>> Perhaps, `@link` for the `getImageLoadStatus` method would work better: it allows viewing the description of the method and its purpose; in its turn, `getImageLoadStatus` references possible return values including `MediaTracker.ERRORED` with `@see` tag.
>
> Indeed, this is not supported, the generated javadoc looks like this:
> 
> ??and `getImageLoadStatus()` will report .?
> 
> Therefore I suggest the following:
> 
> 
>  * {@link #getImageLoadStatus()} will report {@code MediaTracker.ERRORED}.

modified

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2239692279

From aivanov at openjdk.org  Tue Jul 29 13:04:10 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 13:04:10 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v23]
In-Reply-To: <FlrPHhl3ZJGFczIog1baWeU2ws1UZCnQldPRY4jRadY=.89bf0864-dc3d-42bc-82ce-bab9c7631c45@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <FlrPHhl3ZJGFczIog1baWeU2ws1UZCnQldPRY4jRadY=.89bf0864-dc3d-42bc-82ce-bab9c7631c45@github.com>
Message-ID: <vE83kUGrSSTsBfUBLvWAnvrz46QsWnmpzkmrcMpBgMA=.a9d04837-340a-436d-bd38-2a82a447ad36@github.com>

On Tue, 29 Jul 2025 12:44:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rectify @throws clause, update test to delete file

`ImageIcon` changes look good to me.

I admit I can't understand what the test is doing, and I don't have to time to study the test thoroughly.

However, I'm still for documenting null and invalid parameters under a separate bug id; under this bug id modify `Image.setImage` to accept `null` as it's reported in the bug ([JDK-8159055](https://bugs.openjdk.org/browse/JDK-8159055)) and as it was done in this PR initially.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25767#pullrequestreview-3067442617

From aivanov at openjdk.org  Tue Jul 29 13:13:03 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 13:13:03 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v23]
In-Reply-To: <FlrPHhl3ZJGFczIog1baWeU2ws1UZCnQldPRY4jRadY=.89bf0864-dc3d-42bc-82ce-bab9c7631c45@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <FlrPHhl3ZJGFczIog1baWeU2ws1UZCnQldPRY4jRadY=.89bf0864-dc3d-42bc-82ce-bab9c7631c45@github.com>
Message-ID: <Kl5s9XrbWsvjQxE2kEYqOh5rr2ejVkOI6hgWu5dq63o=.5c906f90-2a87-4abb-9012-10fc61701e8e@github.com>

On Tue, 29 Jul 2025 12:44:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rectify @throws clause, update test to delete file

test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 54:

> 52:         File file = new File(imgName);
> 53:         file.deleteOnExit();
> 54:         String fileName = file.getName();

Don't `imgName` and `fileName` store the same value now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2239786008

From psadhukhan at openjdk.org  Tue Jul 29 14:13:40 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 14:13:40 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v23]
In-Reply-To: <Kl5s9XrbWsvjQxE2kEYqOh5rr2ejVkOI6hgWu5dq63o=.5c906f90-2a87-4abb-9012-10fc61701e8e@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <FlrPHhl3ZJGFczIog1baWeU2ws1UZCnQldPRY4jRadY=.89bf0864-dc3d-42bc-82ce-bab9c7631c45@github.com>
 <Kl5s9XrbWsvjQxE2kEYqOh5rr2ejVkOI6hgWu5dq63o=.5c906f90-2a87-4abb-9012-10fc61701e8e@github.com>
Message-ID: <AH2eN4TvsvHch5Jww16BClLtiWynGR-vdTsOGVZtP3U=.dd073825-4dfe-434c-96f5-616acec5b50f@github.com>

On Tue, 29 Jul 2025 13:09:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rectify @throws clause, update test to delete file
>
> test/jdk/javax/swing/ImageIcon/ImageIconTest.java line 54:
> 
>> 52:         File file = new File(imgName);
>> 53:         file.deleteOnExit();
>> 54:         String fileName = file.getName();
> 
> Don't `imgName` and `fileName` store the same value now?

yes removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2239967294

From psadhukhan at openjdk.org  Tue Jul 29 14:13:39 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 29 Jul 2025 14:13:39 GMT
Subject: RFR: 8159055: ImageIcon.setImage can't handle null parameter [v24]
In-Reply-To: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
Message-ID: <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>

> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
> 
> It's better to not go through all MediaTracker usage and bail out initially itself for null image..

Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:

 - Modify summary
 - Modify summary
 - Remove redundant fileName param

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25767/files
  - new: https://git.openjdk.org/jdk/pull/25767/files/a31f51a4..85f2a841

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25767&range=22-23

  Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25767/head:pull/25767

PR: https://git.openjdk.org/jdk/pull/25767

From prr at openjdk.org  Tue Jul 29 16:59:02 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 29 Jul 2025 16:59:02 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v24]
In-Reply-To: <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
Message-ID: <pzujg0SPelG37Jy6C2eSYImIgYDABN2fyayInCS0NWQ=.bcf5fdeb-1ee2-41db-b961-bde8de370d4a@github.com>

On Tue, 29 Jul 2025 14:13:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Modify summary
>  - Modify summary
>  - Remove redundant fileName param

> Currently, [JDK-8159055](https://bugs.openjdk.org/browse/JDK-8159055) is an enhancement which made sense while the goal of this PR was to change `Image.setImage` so that it accepts `null` as parameter.
> 
> After a month of discussions, that solution has been abandoned, instead it is stated that `Image.setImage` will throw `NullPointerException` if `image` parameter is `null`.
> 
> I think the type of JDK-8159055 should be changed to _bug_.

I agree. Not saying how null is handled is a bug. So fixing it is a bug fix, not an enhancement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25767#issuecomment-3133333056

From prr at openjdk.org  Tue Jul 29 17:10:55 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 29 Jul 2025 17:10:55 GMT
Subject: RFR: 8363889: Update sun.print.PrintJob2D to use Disposer [v2]
In-Reply-To: <U5IXVBLBrohzF3siWITFjykdL5nakfYWt0jyNkQmfWI=.7301007d-113a-4b2f-85b0-2373a6717104@github.com>
References: <IPtDBZTE0zjLhU-cTfErrQuE9i99u8ws7TwAfw87L98=.45de751e-57e4-4a5a-ade6-334a03d9e7a0@github.com>
 <IcREgEvuGA6WaoKh1_4Usq1pAqxcCvF3jWwhesma-Rk=.75a0ff69-b2ff-4c0a-b56a-312abd14f428@github.com>
 <U5IXVBLBrohzF3siWITFjykdL5nakfYWt0jyNkQmfWI=.7301007d-113a-4b2f-85b0-2373a6717104@github.com>
Message-ID: <oCTnJziK-OrVOGb70Db4FIKM8v5BaN9CxltxLWYikoY=.6ed61013-d497-4e15-80e9-62549555d3b3@github.com>

On Tue, 29 Jul 2025 12:09:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8363889
>
> src/java.desktop/share/classes/sun/print/PrintJobDelegate.java line 123:
> 
>> 121:         MediaSizeName.ISO_A10, MediaSizeName.ISO_B0, MediaSizeName.ISO_B1,
>> 122:         MediaSizeName.ISO_B2, MediaSizeName.ISO_B3, MediaSizeName.ISO_B4,
>> 123:         MediaSizeName.ISO_B5,  MediaSizeName.ISO_B6, MediaSizeName.ISO_B7,
> 
> Suggestion:
> 
>         MediaSizeName.ISO_B5, MediaSizeName.ISO_B6, MediaSizeName.ISO_B7,

I just moved all this code because I had to. I'm not intending to spend time looking for errant spaces - or fixing them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26432#discussion_r2240466419

From prr at openjdk.org  Tue Jul 29 17:24:56 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 29 Jul 2025 17:24:56 GMT
Subject: RFR: 8364135: JPEGImageReader.getImageTypes() should throw
 exception for non-zero image index
In-Reply-To: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
References: <6wn8ZHj2ApRHTzASuhqjo8w6ctBBOT8I7IaCZkuioIk=.64e95fdb-daf9-4c79-a797-f7a404c75cae@github.com>
Message-ID: <4bimZDOPVXTxOjjE24uTit147oJO3_7-m4gDEg49tWs=.6a416335-c2e3-47f6-85d3-cba38b9b38ce@github.com>

On Tue, 29 Jul 2025 05:38:00 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We need to throw appropriate exception when we pass invalid image index values to ImageReader.getImageTypes().
> We throw IOOBE in all other plugins except JPEG, Added appropriate check to throw IOOBE when JpegImageReader has invalid image index.

src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java line 907:

> 905:         if (imageIndex != 0) {
> 906:             throw new IndexOutOfBoundsException("imageIndex != 0!");
> 907:         }

There are JPEG streams with > 1.
And elsewhere we handle it. Look at hasNextImage()

Is this method the sole place where -1 would not throw the right exception ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26522#discussion_r2240495436

From prr at openjdk.org  Tue Jul 29 17:29:55 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 29 Jul 2025 17:29:55 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

If PNG_LOONGARCH_LSX_OPT is set to 0 it disables all those extra fns
https://github.com/openjdk/jdk/pull/18964/files

So LGTM.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26501#pullrequestreview-3068524024

From duke at openjdk.org  Tue Jul 29 17:32:57 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 29 Jul 2025 17:32:57 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
Message-ID: <gSfttZ6pDCc8bCwxdgVnqu6ZSY61P8-loU_j1UyynYI=.2f7de1e5-378b-46eb-8e41-202a2493b11b@github.com>

On Tue, 29 Jul 2025 11:56:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use named property listener, update test

Is the PropertyChangeEvent fired *immediately* as the component is added/removed, or is the notification delayed in an invoke-later somewhere? Because if it's delayed: we can check to make sure the information is still relevant.

There are some (probably "bad") UIs that rebuild the UI constantly: they call container.removeAll() and then re-add child components. The end result is usually that the user doesn't perceive a change because the container is stripped and re-built to resemble its original state.

But those UIs may suffer under this PR. (That is: as soon as component is removed the popup is hidden, even if that component is immediately re-added.)

To be clear: I like this PR and have no objection to going forward with it. I think the UI's I'm describing here are badly designed. But it is a potential unintended consequence to consider.

(I can draft a quick example if needed.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3133426454

From prr at openjdk.org  Tue Jul 29 18:11:02 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 29 Jul 2025 18:11:02 GMT
Subject: RFR: JDK-8361748 : Enforce limits on the size of an XBM image [v2]
In-Reply-To: <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
References: <KO4wgW36TrkDxrsTm_Yy5q8rjyzU1727HF9CNvNbI3I=.d500ef6e-1dbe-4793-b73a-3cc6f5f0666a@github.com>
 <J5S_nCU-LS2qPvjfUdnvrCY8T0l_2mps0DT8ayV93Rc=.4d53f2c8-1eac-4c01-bd6b-1c1a4efb6b08@github.com>
Message-ID: <5TROm-dHmyBNxiC8iDPsUHe0Zg_mryw1iXSrzDSqTEM=.7111046f-79e5-4b29-9897-59ce2238551d@github.com>

On Fri, 25 Jul 2025 23:58:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> XBM (X Bitmap) images are small one-bit deep images that were developed as a simple uncompressed format that could easily be included in C source files as include files.
>> 
>> Format of XBM image:
>> 
>> 
>>  #define width w
>>  #define height h
>>  static char foo_bits[] = {
>>  0xnn,0xnn,0xnn,0xnn,0xnn, .......
>>  0xnn,0xnn,0xnn,0xnn, .........
>>  0xnn,0xnn,0xnn,0xnn};
>> 
>> 
>> The first two #defines statements specify the width and height of the bitmap in pixels followed by hex byte array which represent pixel data itself.
>> 
>> The current implementation allows an arbitrarily large XBM which is not a valid use case for any XBM.
>> Also it doesn't validate that the provided byte array is sufficient to populate the specified WxH. Since these are small one-bit mono images a reasonable size limit is set to `MAX_XBM_SIZE = 16384 bytes`. It can be set to a larger limit if someone thinks it is necessary.
>> 
>> The XBMDecoder's produceImage() has outdated logic, it has been restructured by adding more efficient parser logic and better error handling checks.
>
> Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename
>  - test summary

LGTM

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26488#pullrequestreview-3068654119

From prr at openjdk.org  Tue Jul 29 19:00:09 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 29 Jul 2025 19:00:09 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v24]
In-Reply-To: <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
Message-ID: <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>

On Tue, 29 Jul 2025 14:13:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When trying to call 'icon.setImage(null);' where 'icon' is an instance of ImageIcon, a null pointer exception is thrown at runtime.
>> The code tried to get the `id` for that image and instantiates `MediaTracker` to associate the null image to that `id` and checks the status of loading this null image, removes the null image from the tracker and then tries to get the image width where it throws NPE as image is null.
>> 
>> It's better to not go through all MediaTracker usage and bail out initially itself for null image..
>
> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Modify summary
>  - Modify summary
>  - Remove redundant fileName param

src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:

> 66:  * If the image source parameter to a constructor or method is non-null,
> 67:  * but does not reference valid accessible image data,
> 68:  * no exceptions will be thrown but the image will be unset,

"will behave as if unset" ?
or maybe 
"will behave as if uninitialized " ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2240693577

From aivanov at openjdk.org  Tue Jul 29 20:33:00 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 20:33:00 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v24]
In-Reply-To: <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
 <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>
Message-ID: <2HxKa-IQFkckWDq510ExKlX4A7eRwjxB4wYU4_nstD4=.e298b231-2942-49a7-9a9e-4054357539a0@github.com>

On Tue, 29 Jul 2025 18:55:47 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Modify summary
>>  - Modify summary
>>  - Remove redundant fileName param
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:
> 
>> 66:  * If the image source parameter to a constructor or method is non-null,
>> 67:  * but does not reference valid accessible image data,
>> 68:  * no exceptions will be thrown but the image will be unset,
> 
> "will behave as if unset" ?
> or maybe 
> "will behave as if uninitialized " ?

?will behave as if the image is null??

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2240940261

From aivanov at openjdk.org  Tue Jul 29 20:47:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 29 Jul 2025 20:47:59 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
Message-ID: <rxhvG51X1coq9xgdbdAo0m0F2eTOYCQmz4sSePw5vJ8=.88af3614-2526-4d13-a2d3-fd0fc7d5470e@github.com>

On Tue, 29 Jul 2025 11:56:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use named property listener, update test

> Is the PropertyChangeEvent fired _immediately_ as the component is added/removed, or is the notification delayed in an invoke-later somewhere? Because if it's delayed: we can check to make sure the information is still relevant.

Yes, it's fired immediately. See the piece of code in the PR description, I'm quoting here for convenience too:

https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858

> There are some (probably "bad") UIs that rebuild the UI constantly: they call container.removeAll() and then re-add child components. The end result is usually that the user doesn't perceive a change because the container is stripped and re-built to resemble its original state.
> 
> But those UIs may suffer under this PR. (That is: as soon as component is removed the popup is hidden, even if that component is immediately re-added.)

In this case, if the UI is rebuilt this way while a popup is displayed on the screen, the popup will be hidden.

Usually, UI is rebuilt in reaction to an event? such as an action (button press, menu selection), so we may expect the popup is already hidden.

> To be clear: I like this PR and have no objection to going forward with it. I think the UI's I'm describing here are badly designed. But it is a potential unintended consequence to consider.

You're right. However, what would be the expected behaviour? Hiding the displayed popup when its owner is removed from the component hierarchy, or ensuring the displayed popup remains visible?

The former looks reasonable enough to me. If it's the latter, then there's no bug to fix and we can just leave the code unmodified.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3134020173

From achung at openjdk.org  Tue Jul 29 21:40:46 2025
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 29 Jul 2025 21:40:46 GMT
Subject: RFR: 8150564: Migrate useful ExtendedRobot methods into awt.Robot
 [v27]
In-Reply-To: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
References: <ldm4oJEWcY_gp23f9QybFXDlWNU2GFt9-t1_PS5g0CY=.535442a6-8359-4808-8062-de8d7b1a9c04@github.com>
Message-ID: <eCmW66NgKnH5_U95zw397epT6L56urIJvBep6CZsFzc=.2a90af5c-1f36-4f70-bb3c-37730d76a7ad@github.com>

> Some useful methods in ExtendedRobot should be migrated into Robot itself so that ExtendedRobot can be removed in the future. The tests using ExtendedRobot for these migrated methods are changed to use only Robot (removing unnecessary building of ExtendedRobot).

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  revert robot set/get for step delay/length and readd glide(int,int,int,int,int,int), remove restriction on dist < stepLength and corresponding IAE from spec

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22044/files
  - new: https://git.openjdk.org/jdk/pull/22044/files/ead01714..c0b1a260

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22044&range=25-26

  Stats: 109 lines in 1 file changed: 32 ins; 63 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/22044.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22044/head:pull/22044

PR: https://git.openjdk.org/jdk/pull/22044

From duke at openjdk.org  Tue Jul 29 22:19:54 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 29 Jul 2025 22:19:54 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <rxhvG51X1coq9xgdbdAo0m0F2eTOYCQmz4sSePw5vJ8=.88af3614-2526-4d13-a2d3-fd0fc7d5470e@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <rxhvG51X1coq9xgdbdAo0m0F2eTOYCQmz4sSePw5vJ8=.88af3614-2526-4d13-a2d3-fd0fc7d5470e@github.com>
Message-ID: <gC11iSSO-IPZjt1IKI_tSsTIipuH6pIptmGLl84npao=.b978cce9-65ee-4325-a5c3-7aca9577f302@github.com>

On Tue, 29 Jul 2025 20:45:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> what would be the expected behaviour?

I'm not sure.

If I was maintaining code with this bad rebuilding pattern: I'd appreciate it if this PR's new listener was something I could toggle off or nullify. (For ex: if it was `protected` instead of `private`). Or if it invoked a protected JPopupMenu method I could override.

But I'm not currently maintaining any such code, and I think overall this PR is worth accepting as-is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26407#issuecomment-3134230270

From duke at openjdk.org  Tue Jul 29 22:38:57 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Tue, 29 Jul 2025 22:38:57 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
Message-ID: <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>

On Tue, 29 Jul 2025 11:56:49 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use named property listener, update test

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1427:

> 1425:             indexCounter++;
> 1426:         }
> 1427:     }

This may be a naive question: is the lambda we use for `propListener` Serializable?

(If so: great. If not: won't we get inconsistent results if we're working with a deserialized copy of a JPopupMenu? The original will have a non-null `propListener` field, and the copy will have a null `propListener`? Or am I missing something?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2241147333

From psadhukhan at openjdk.org  Wed Jul 30 03:47:00 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 30 Jul 2025 03:47:00 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>
Message-ID: <c2V-6ZDF9g7sddWjdKZsr0ozeop3-QpPpzowvWZuk5k=.02a4f290-2f85-4557-8d82-59d0ad2f7e87@github.com>

On Tue, 29 Jul 2025 22:36:09 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use named property listener, update test
>
> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1427:
> 
>> 1425:             indexCounter++;
>> 1426:         }
>> 1427:     }
> 
> This may be a naive question: is the lambda we use for `propListener` Serializable?
> 
> (If so: great. If not: won't we get inconsistent results if we're working with a deserialized copy of a JPopupMenu? The original will have a non-null `propListener` field, and the copy will have a null `propListener`? Or am I missing something?)

It is transient so  its value should not be included in the default serialization process in my opinion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2241461858

From psadhukhan at openjdk.org  Wed Jul 30 04:20:47 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 30 Jul 2025 04:20:47 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v37]
In-Reply-To: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
Message-ID: <dSf67UgRj_LGBprC0tZ4M6ZJ8y9H5fEOjGs4BgA7QXQ=.4e97a2d3-a132-4b98-9792-ad6c2141b642@github.com>

> When JRadioButtonMenuItem is called with imageIcon, then only imageIcon is shown without radiobutton in WIndowsLookAndFeel as there was no provision of drawing the radiobutton alongside icon.
> If icon is not there, the radiobutton is drawn. Added provision of drawing the radiobutton windows Skin even when imageIcon is present.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix not needed background effect for Windows 10

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23324/files
  - new: https://git.openjdk.org/jdk/pull/23324/files/c5f5ce29..a3264c78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23324&range=35-36

  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23324/head:pull/23324

PR: https://git.openjdk.org/jdk/pull/23324

From psadhukhan at openjdk.org  Wed Jul 30 04:23:59 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 30 Jul 2025 04:23:59 GMT
Subject: RFR: 8348760: RadioButton is not shown if JRadioButtonMenuItem is
 rendered with ImageIcon in WindowsLookAndFeel [v36]
In-Reply-To: <-sTaNO0-W1ESyxmOUW4GqIJLPHHHCX27wJwOTSUc0-s=.5d905699-24b9-40b6-b4ec-a1c68c9f80e9@github.com>
References: <_OqONGmbeH9KtcJvhT_kMpl5xZ8hTN-VvOat7vWFjsI=.c0bb8661-5c33-433c-a722-a39153f63df2@github.com>
 <FVhRfLRjStIosXDDhAVCkQxYLnnel4fpqAFly3UhnrA=.fd1ec703-4ae4-4312-b38b-028afe57d2b1@github.com>
 <eCpPcLQCzhSMmIbaCudrL8iz0fXdXzXMMxUSDg7yTiY=.b71dda32-21c8-46c2-8c14-5c1f4799970e@github.com>
 <-sTaNO0-W1ESyxmOUW4GqIJLPHHHCX27wJwOTSUc0-s=.5d905699-24b9-40b6-b4ec-a1c68c9f80e9@github.com>
Message-ID: <3NjgI-NGLTqUvHeoOMcRTv84b7-kST2FFFFdr0qiRXI=.cc27fd55-94b3-4649-8f67-bd54e35e87f0@github.com>

On Sun, 27 Jul 2025 09:56:45 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > Did you update your Windows 10 to latest version? I guess it was told by Microsoft as reported by Phil that "the visual "cue" we've relied on for in Windows 10 was just an accident of some theming that is now gone.
> > so I thought the skin background blue effect would have been replaced in the "new theme"
> 
> Yes, i'm on the latest version of Windows 10. I think what Microsoft rep meant is that this behavior was fixed in Windows 11 but i do not think they ever tried to fix it in W10 and now when W10 is at the EOL they never will.

Yes I also thought so and for that eventuality I had the version check 
but now since that is removed and we need to unify the code both for Windows 10 and 11 I have updated the PR to fix this

With the latest fix in Windows 11, it looks like this (no change visually from previous) 

<img width="421" height="383" alt="image" src="https://github.com/user-attachments/assets/26f6330c-8067-480f-b29b-f0fce9544db5" />


but it will cause Windows 10 to look like Windows 11..

<img width="352" height="346" alt="image" src="https://github.com/user-attachments/assets/81d99fd8-98b7-40de-8ded-a47df8934625" />

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23324#issuecomment-3134805655

From psadhukhan at openjdk.org  Wed Jul 30 04:30:02 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 30 Jul 2025 04:30:02 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v24]
In-Reply-To: <2HxKa-IQFkckWDq510ExKlX4A7eRwjxB4wYU4_nstD4=.e298b231-2942-49a7-9a9e-4054357539a0@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
 <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>
 <2HxKa-IQFkckWDq510ExKlX4A7eRwjxB4wYU4_nstD4=.e298b231-2942-49a7-9a9e-4054357539a0@github.com>
Message-ID: <VSRqWMHcU8m-GE_TM1SEqJkwyES6jnvrln-gQqG2usY=.37eaf4d8-0d3a-4774-975e-8197dd8a4359@github.com>

On Tue, 29 Jul 2025 20:30:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:
>> 
>>> 66:  * If the image source parameter to a constructor or method is non-null,
>>> 67:  * but does not reference valid accessible image data,
>>> 68:  * no exceptions will be thrown but the image will be unset,
>> 
>> "will behave as if unset" ?
>> or maybe 
>> "will behave as if uninitialized " ?
>
> ?will behave as if the image is null??

My take is if we have to explain further, we can use 
"no exceptions will be thrown but no image icon will be rendered"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2241499719

From duke at openjdk.org  Wed Jul 30 04:44:01 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 30 Jul 2025 04:44:01 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <c2V-6ZDF9g7sddWjdKZsr0ozeop3-QpPpzowvWZuk5k=.02a4f290-2f85-4557-8d82-59d0ad2f7e87@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>
 <c2V-6ZDF9g7sddWjdKZsr0ozeop3-QpPpzowvWZuk5k=.02a4f290-2f85-4557-8d82-59d0ad2f7e87@github.com>
Message-ID: <4UqebAsi-WEmkX_Ngyi23eDLvIyvsH0VlR58UdDSAn8=.75c4f4f4-7df1-494e-a7d7-17125ef1b195@github.com>

On Wed, 30 Jul 2025 03:44:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 1427:
>> 
>>> 1425:             indexCounter++;
>>> 1426:         }
>>> 1427:     }
>> 
>> This may be a naive question: is the lambda we use for `propListener` Serializable?
>> 
>> (If so: great. If not: won't we get inconsistent results if we're working with a deserialized copy of a JPopupMenu? The original will have a non-null `propListener` field, and the copy will have a null `propListener`? Or am I missing something?)
>
> It is transient so  its value should not be included in the default serialization process in my opinion

I'm fine with `propListener` being transient ... as long as when we call readObject() we still make a point to initialize `propListener`.

Here's a unit test that demonstrates what I'm worried about:

import javax.swing.*;
import java.beans.PropertyChangeListener;
import java.io.*;

public class JPopupMenuSerializationTest {
    static class JPopupMenuSubclass extends JPopupMenu implements Serializable {
        private transient PropertyChangeListener propListener =
                (e) -> {
                    if (e.getOldValue() != null
                            && e.getNewValue() == null
                            && isVisible()) {
                        setVisible(false);
                    }
                };

        @Serial
        private void writeObject(ObjectOutputStream s) throws IOException {
            Object serializable = propListener instanceof Serializable ?
                    (Serializable) propListener : null;
            System.out.println("Serialized: " + serializable);
            s.writeObject(serializable);
        }

        @Serial
        private void readObject(ObjectInputStream s)
                throws IOException, ClassNotFoundException {
            PropertyChangeListener l = (PropertyChangeListener) s.readObject();
            System.out.println("Deserialized: " + l);
            if (l != null) {
                propListener = l;
            }
            System.out.println("propListener: " + propListener);
        }
    }

    public static void main(String[] args) throws Exception {
        JPopupMenuSerializationTest test = new JPopupMenuSerializationTest();
        test.testSerialization();
    }

    public void testSerialization() throws Exception {
        JPopupMenuSubclass popupMenu = new JPopupMenuSubclass();
        byte[] data = serialize(popupMenu);
        JPopupMenuSubclass copy = deserialize(data);

        assertTrue("original.propListener should exist", popupMenu.propListener != null);

        // currently this fails, and IMO it should pass:
        assertTrue("copy.propListener should exist",  copy.propListener != null);
    }

    private static void assertTrue(String errorMsg, boolean b) {
        if (!b)
            throw new Error(errorMsg);
    }

    private static byte[] serialize(JPopupMenuSubclass popupMenu) throws IOException {
        try (ByteArrayOutputStream byteOut = new ByteArrayOutputStream()) {
            try (ObjectOutputStream objOut = new ObjectOutputStream(byteOut)) {
                objOut.writeObject(popupMenu);
            }
            return byteOut.toByteArray();
        }
    }

    private static JPopupMenuSubclass deserialize(byte[] data) throws IOException, ClassNotFoundException {
        try (ByteArrayInputStream byteIn = new ByteArrayInputStream(data)) {
            try (ObjectInputStream objIn = new ObjectInputStream(byteIn)) {
                return (JPopupMenuSubclass) objIn.readObject();
            }
        }
    }
}


Currently on my machine this outputs:

Serialized: null
Deserialized: null
propListener: null
Exception in thread "main" java.lang.Error: copy.propListener should exist
	at JPopupMenuSerializationTest.assertTrue(JPopupMenuSerializationTest.java:54)
	at JPopupMenuSerializationTest.testSerialization(JPopupMenuSerializationTest.java:49)
	at JPopupMenuSerializationTest.main(JPopupMenuSerializationTest.java:38)


This means (I think?) a deserialized copy is going to act different than the original, right? (I'm not an expert on serializing UI components, so maybe I'm missing something...?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2241513779

From psadhukhan at openjdk.org  Wed Jul 30 05:14:58 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 30 Jul 2025 05:14:58 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <4UqebAsi-WEmkX_Ngyi23eDLvIyvsH0VlR58UdDSAn8=.75c4f4f4-7df1-494e-a7d7-17125ef1b195@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>
 <c2V-6ZDF9g7sddWjdKZsr0ozeop3-QpPpzowvWZuk5k=.02a4f290-2f85-4557-8d82-59d0ad2f7e87@github.com>
 <4UqebAsi-WEmkX_Ngyi23eDLvIyvsH0VlR58UdDSAn8=.75c4f4f4-7df1-494e-a7d7-17125ef1b195@github.com>
Message-ID: <E2AHJb6cDV0vetYEuAVsAX7gAnDLg9vnMCGx9VVaepo=.6adebba2-aacb-4496-ba3b-d9d9ac8105b9@github.com>

On Wed, 30 Jul 2025 04:41:41 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> It is transient so  its value should not be included in the default serialization process in my opinion
>
> I'm fine with `propListener` being transient ... as long as when we call readObject() we still initialize `propListener`.
> 
> Here's a unit test that demonstrates what I'm worried about:
> 
> import javax.swing.*;
> import java.beans.PropertyChangeListener;
> import java.io.*;
> 
> public class JPopupMenuSerializationTest {
>     static class JPopupMenuSubclass extends JPopupMenu implements Serializable {
>         private transient PropertyChangeListener propListener =
>                 (e) -> {
>                     if (e.getOldValue() != null
>                             && e.getNewValue() == null
>                             && isVisible()) {
>                         setVisible(false);
>                     }
>                 };
> 
>         @Serial
>         private void writeObject(ObjectOutputStream s) throws IOException {
>             Object serializable = propListener instanceof Serializable ?
>                     (Serializable) propListener : null;
>             System.out.println("Serialized: " + serializable);
>             s.writeObject(serializable);
>         }
> 
>         @Serial
>         private void readObject(ObjectInputStream s)
>                 throws IOException, ClassNotFoundException {
>             PropertyChangeListener l = (PropertyChangeListener) s.readObject();
>             System.out.println("Deserialized: " + l);
>             if (l != null) {
>                 propListener = l;
>             }
>             System.out.println("propListener: " + propListener);
>         }
>     }
> 
>     public static void main(String[] args) throws Exception {
>         JPopupMenuSerializationTest test = new JPopupMenuSerializationTest();
>         test.testSerialization();
>     }
> 
>     public void testSerialization() throws Exception {
>         JPopupMenuSubclass popupMenu = new JPopupMenuSubclass();
>         byte[] data = serialize(popupMenu);
>         JPopupMenuSubclass copy = deserialize(data);
> 
>         assertTrue("original.propListener should exist", popupMenu.propListener != null);
> 
>         // currently this fails, and IMO it should pass:
>         assertTrue("copy.propListener should exist",  copy.propListener != null);
>     }
> 
>     private static void assertTrue(String errorMsg, boolean b) {
>         if (!b)
>             throw new Error(errorMsg);
>     }
> 
>     private static byte[] serialize(JPopupMenuSubclass popupMenu) throws IOException {
>         try (ByteArrayOutputStream byteOut = new ByteArrayOutputStream()) {
>             try (ObjectOutputStream objOut = new ObjectOutputStream(byteOut)) {
>                 objO...

Hmm..We need to take a look at how to handle serialization aspect of propListener

but as per https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#serialization


> You can serialize a lambda expression if its target type and its captured arguments are serializable. However, like inner classes, the serialization of lambda expressions is strongly discouraged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2241547175

From aoqi at openjdk.org  Wed Jul 30 05:20:04 2025
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 30 Jul 2025 05:20:04 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
 <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>
Message-ID: <NFXjSBniq1o_pHDc4JrSG4ugj9pIQFwkidWpYg3o65s=.2142775b-bb7a-4c46-ba5e-dddfd4c89c6b@github.com>

On Tue, 29 Jul 2025 17:27:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
>> 
>> 
>> #ifndef PNG_LOONGARCH_LSX_OPT
>> # if defined(__loongarch_sx)
>> # define PNG_LOONGARCH_LSX_OPT 1
>> # else
>> # define PNG_LOONGARCH_LSX_OPT 0
>> # endif
>> #endif
>> 
>> 
>> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.
>
> If PNG_LOONGARCH_LSX_OPT is set to 0 it disables all those extra fns
> https://github.com/openjdk/jdk/pull/18964/files
> 
> So LGTM.

Thanks for the review, @prrace. Is a second reviewer needed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3134883377

From duke at openjdk.org  Wed Jul 30 05:34:55 2025
From: duke at openjdk.org (Jeremy Wood)
Date: Wed, 30 Jul 2025 05:34:55 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <E2AHJb6cDV0vetYEuAVsAX7gAnDLg9vnMCGx9VVaepo=.6adebba2-aacb-4496-ba3b-d9d9ac8105b9@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>
 <c2V-6ZDF9g7sddWjdKZsr0ozeop3-QpPpzowvWZuk5k=.02a4f290-2f85-4557-8d82-59d0ad2f7e87@github.com>
 <4UqebAsi-WEmkX_Ngyi23eDLvIyvsH0VlR58UdDSAn8=.75c4f4f4-7df1-494e-a7d7-17125ef1b195@github.com>
 <E2AHJb6cDV0vetYEuAVsAX7gAnDLg9vnMCGx9VVaepo=.6adebba2-aacb-4496-ba3b-d9d9ac8105b9@github.com>
Message-ID: <QAkuElS7L9kwqIiEXvtpkgE3kw3Kuh2a06V2m6GkNxk=.b287e92d-eea8-4816-aefe-92508b321b29@github.com>

On Wed, 30 Jul 2025 05:12:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> You can serialize a lambda expression if its target type and its captured arguments are serializable

I think that means `propListener` is NOT going to serialize, because `PropertyChangeListener` isn't `Serializable`. I'm unfamiliar with these details; I found this link helpful: https://www.baeldung.com/java-serialize-lambda

Alternatively: if we put `propListener` in BasicPopupMenuUI: then I think serialization will be less of an issue. `JComponent#ui` is transient, so we don't try to serialize it (and all of its other listeners). This way the JPopupMenu will come out on the other side of deserialization using whatever the L&F is in that setup. This feels good-ish to me.

(I'm assuming most L&F's extend BasicPopupMenuUI?)

This is all just an idea/suggestion; as long as the deserialized JPopupMenu behaves like the original JPopupMenu I think that should be fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2241571712

From abhiscxk at openjdk.org  Wed Jul 30 06:28:50 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 30 Jul 2025 06:28:50 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character P
 is not underline
Message-ID: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>

For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
Test instruction updated to reflect the desired behaviour .

-------------

Commit messages:
 - Test instruction update

Changes: https://git.openjdk.org/jdk/pull/26546/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26546&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361298
  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26546.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26546/head:pull/26546

PR: https://git.openjdk.org/jdk/pull/26546

From abhiscxk at openjdk.org  Wed Jul 30 06:50:00 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 30 Jul 2025 06:50:00 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v5]
In-Reply-To: <-D_WFgPNXfXpyroETEyJ2hc0e-uh78pW7iLklGhZzJ0=.76eeac45-f0a2-4900-b317-0541a6c6a0fc@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <-D_WFgPNXfXpyroETEyJ2hc0e-uh78pW7iLklGhZzJ0=.76eeac45-f0a2-4900-b317-0541a6c6a0fc@github.com>
Message-ID: <lW5M5A5UwpLRCKCAXhVbhaej5TenqRlqlTUqN11uN8U=.7b558426-f9da-4586-8f61-e2a0012556c5@github.com>

On Mon, 21 Jul 2025 07:39:59 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: header update

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 2:

> 1: /*
> 2:  * Copyright (c) 2008, 2026, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2008, 2025, Oracle and/or its affiliates. All rights reserved.

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 29:

> 27:   @bug 6315717
> 28:   @summary verifies that drag events are coming for every button if the property is set to true
> 29:   @run main ExtraButtonDrag

jtreg tag 

/*
  * @test
  * @key headful
  * @bug 6315717
  * @summary verifies that drag events are coming for every button if the property is set to true
  * @run main ExtraButtonDrag
  */

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 50:

> 48:     private static Robot robot;
> 49:     private volatile static boolean dragged = false;
> 50:     private volatile static boolean moved = false;

Suggestion:

    private static volatile boolean dragged = false;
    private static volatile boolean moved = false;

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 75:

> 73:         public void mouseReleased(MouseEvent e) {
> 74:             System.out.println("Released " + e);
> 75:         }

You can remove these two overridden methods, it's not required to implement.

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 190:

> 188:             doTest();
> 189: 
> 190:             System.out.println("Test PASSED");

You may also remove this statement else modify.
Suggestion:

            System.out.println("Test Passed");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2241651657
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2241674366
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2241657947
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2241671163
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2241689841

From abhiscxk at openjdk.org  Wed Jul 30 06:59:57 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 30 Jul 2025 06:59:57 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v5]
In-Reply-To: <-D_WFgPNXfXpyroETEyJ2hc0e-uh78pW7iLklGhZzJ0=.76eeac45-f0a2-4900-b317-0541a6c6a0fc@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <-D_WFgPNXfXpyroETEyJ2hc0e-uh78pW7iLklGhZzJ0=.76eeac45-f0a2-4900-b317-0541a6c6a0fc@github.com>
Message-ID: <sVmptBsdbMpyhGXY4fjwjEb0S3UHO8MQDylCJS-byjg=.973c4010-9205-46c3-b02d-e8dcf8d0bfa4@github.com>

On Mon, 21 Jul 2025 07:39:59 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: header update

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 57:

> 55:         @Override
> 56:         public void mouseDragged(MouseEvent e) {
> 57:             System.out.println("Dragged " + e);

Is it required to log the event ? 
Seems too much logging.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2241711182

From psadhukhan at openjdk.org  Wed Jul 30 09:56:41 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 30 Jul 2025 09:56:41 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v7]
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <NqoLKH6_7G9Fwj7gNUYYXAz9Y7QXirrz4ZrF7giScNE=.c05b5998-c241-4149-81e5-f0fb9c7c564c@github.com>

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Serialization fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26407/files
  - new: https://git.openjdk.org/jdk/pull/26407/files/8af3c94d..fd4cdea2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26407&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26407&range=05-06

  Stats: 18 lines in 1 file changed: 10 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26407/head:pull/26407

PR: https://git.openjdk.org/jdk/pull/26407

From psadhukhan at openjdk.org  Wed Jul 30 09:56:41 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 30 Jul 2025 09:56:41 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <QAkuElS7L9kwqIiEXvtpkgE3kw3Kuh2a06V2m6GkNxk=.b287e92d-eea8-4816-aefe-92508b321b29@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>
 <c2V-6ZDF9g7sddWjdKZsr0ozeop3-QpPpzowvWZuk5k=.02a4f290-2f85-4557-8d82-59d0ad2f7e87@github.com>
 <4UqebAsi-WEmkX_Ngyi23eDLvIyvsH0VlR58UdDSAn8=.75c4f4f4-7df1-494e-a7d7-17125ef1b195@github.com>
 <E2AHJb6cDV0vetYEuAVsAX7gAnDLg9vnMCGx9VVaepo=.6adebba2-aacb-4496-ba3b-d9d9ac8105b9@github.com>
 <QAkuElS7L9kwqIiEXvtpkgE3kw3Kuh2a06V2m6GkNxk=.b287e92d-eea8-4816-aefe-92508b321b29@github.com>
Message-ID: <8edaFrwzz4wTmP7dsJphHdhcLQNXNPficreToIbypYI=.f82f5fee-90d9-431b-950d-2a68da02d9ce@github.com>

On Wed, 30 Jul 2025 05:32:25 GMT, Jeremy Wood <duke at openjdk.org> wrote:

>> Hmm..We need to take a look at how to handle serialization aspect of propListener
>> 
>> but as per https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#serialization
>> 
>> 
>>> You can serialize a lambda expression if its target type and its captured arguments are serializable. However, like inner classes, the serialization of lambda expressions is strongly discouraged.
>
>>> You can serialize a lambda expression if its target type and its captured arguments are serializable
> 
> I think that means `propListener` is NOT going to serialize, because `PropertyChangeListener` isn't `Serializable`. I'm unfamiliar with these details; I found this link helpful: https://www.baeldung.com/java-serialize-lambda
> 
> Alternatively: if we put `propListener` in BasicPopupMenuUI: then I think serialization will be less of an issue. `JComponent#ui` is transient, so we don't try to serialize it (and all of its other listeners). This way the JPopupMenu will come out on the other side of deserialization using whatever the L&F is in that setup. This feels good-ish to me.
> 
> (I'm assuming most L&F's extend BasicPopupMenuUI?)
> 
> This is all just an idea/suggestion; as long as the deserialized JPopupMenu behaves like the original JPopupMenu I think that should be fine.

Yes, it seems deserialized JPopupMenu fails hiding the popup menu owing to `propListener` not getting serialized.

Tried with modified testcase of yours and fixed in latest PR


import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.beans.PropertyChangeListener;
import java.io.*;

public class JPopupMenuSerializationTest {

    public static class MyThread implements Runnable {
        static Container box;
        static Component invo;

        public MyThread(Container cont, Component comp) {
            this.invo = comp;
            this.box = cont;
        }

        public void run() {
            System.out.println("Starting 3 second countdown...");
            try{
                Thread.currentThread().sleep(3000);
            } catch (Exception e) {}
            System.out.println("Removing popup invoker from the container.");
            box.remove(invo);
            box.repaint();
        }
    }

    public static void main(String[] args) throws Exception {
        JPopupMenuSerializationTest test = new JPopupMenuSerializationTest();
        test.testSerialization();
    }

    public void testSerialization() throws Exception {
        JPopupMenu popupMenu = new JPopupMenu();
        byte[] data = serialize(popupMenu);
        JPopupMenu copy = deserialize(data);

        test(copy);
    }

    private void test(JPopupMenu jpm) {
        JFrame frame = new JFrame("My frame");
        final Container pane = frame.getContentPane();
        pane.setLayout(new BorderLayout());
        pane.add(new JTextField("", 20), BorderLayout.NORTH);
        JButton btn = new JButton("Exit");
        final Thread[] thr = new Thread[] { null };
        btn.setAction(new AbstractAction() {
            public void actionPerformed(ActionEvent ev) {
                System.exit(0);
            }
        });
        btn.setText("Exit");
        pane.add(btn, BorderLayout.SOUTH);
        final JLabel label = new JLabel("Click here to invoke popup");
        label.addMouseListener(new MouseAdapter() {
            public void mouseReleased(MouseEvent e) {
                jpm.add("One");
                jpm.add("Two");
                jpm.add("Three");
                jpm.show(label,
                        label.getLocationOnScreen().x,
                        label.getLocationOnScreen().y);
            }

            public void mousePressed(MouseEvent e) {
                Thread thr = new Thread(new MyThread(pane, label));
                thr.start();
            }
        });
        pane.add(label, BorderLayout.CENTER);
        frame.pack();
        frame.setVisible(true);
    }

    private static byte[] serialize(JPopupMenu popupMenu) throws IOException {
        try (ByteArrayOutputStream byteOut = new ByteArrayOutputStream()) {
            try (ObjectOutputStream objOut = new ObjectOutputStream(byteOut)) {
                objOut.writeObject(popupMenu);
            }
            return byteOut.toByteArray();
        }
    }

    private static JPopupMenu deserialize(byte[] data) throws IOException, ClassNotFoundException {
        try (ByteArrayInputStream byteIn = new ByteArrayInputStream(data)) {
            try (ObjectInputStream objIn = new ObjectInputStream(byteIn)) {
                return (JPopupMenu) objIn.readObject();
            }
        }
    }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2242121247

From aivanov at openjdk.org  Wed Jul 30 13:01:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 30 Jul 2025 13:01:59 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <8edaFrwzz4wTmP7dsJphHdhcLQNXNPficreToIbypYI=.f82f5fee-90d9-431b-950d-2a68da02d9ce@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>
 <c2V-6ZDF9g7sddWjdKZsr0ozeop3-QpPpzowvWZuk5k=.02a4f290-2f85-4557-8d82-59d0ad2f7e87@github.com>
 <4UqebAsi-WEmkX_Ngyi23eDLvIyvsH0VlR58UdDSAn8=.75c4f4f4-7df1-494e-a7d7-17125ef1b195@github.com>
 <E2AHJb6cDV0vetYEuAVsAX7gAnDLg9vnMCGx9VVaepo=.6adebba2-aacb-4496-ba3b-d9d9ac8105b9@github.com>
 <QAkuElS7L9kwqIiEXvtpkgE3kw3Kuh2a06V2m6GkNxk=.b287e92d-eea8-4816-aefe-92508b321b29@github.com>
 <8edaFrwzz4wTmP7dsJphHdhcLQNXNPficreToIbypYI=.f82f5fee-90d9-431b-950d-2a68da02d9ce@github.com>
Message-ID: <ykq2tvTkukB5xhBWdhI7twC-xVKnWBl_kSwgC-F1ilc=.d0c40409-68dc-4695-aa66-08ea227444f1@github.com>

On Wed, 30 Jul 2025 09:53:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>>> You can serialize a lambda expression if its target type and its captured arguments are serializable
>> 
>> I think that means `propListener` is NOT going to serialize, because `PropertyChangeListener` isn't `Serializable`. I'm unfamiliar with these details; I found this link helpful: https://www.baeldung.com/java-serialize-lambda
>> 
>> Alternatively: if we put `propListener` in BasicPopupMenuUI: then I think serialization will be less of an issue. `JComponent#ui` is transient, so we don't try to serialize it (and all of its other listeners). This way the JPopupMenu will come out on the other side of deserialization using whatever the L&F is in that setup. This feels good-ish to me.
>> 
>> (I'm assuming most L&F's extend BasicPopupMenuUI?)
>> 
>> This is all just an idea/suggestion; as long as the deserialized JPopupMenu behaves like the original JPopupMenu I think that should be fine.
>
> Yes, it seems deserialized JPopupMenu fails hiding the popup menu owing to `propListener` not getting serialized.
> 
> Tried with modified testcase of yours and fixed in latest PR
> 
> 
> import java.awt.*;
> import java.awt.event.*;
> import javax.swing.*;
> import java.beans.PropertyChangeListener;
> import java.io.*;
> 
> public class JPopupMenuSerializationTest {
> 
>     public static class MyThread implements Runnable {
>         static Container box;
>         static Component invo;
> 
>         public MyThread(Container cont, Component comp) {
>             this.invo = comp;
>             this.box = cont;
>         }
> 
>         public void run() {
>             System.out.println("Starting 3 second countdown...");
>             try{
>                 Thread.currentThread().sleep(3000);
>             } catch (Exception e) {}
>             System.out.println("Removing popup invoker from the container.");
>             box.remove(invo);
>             box.repaint();
>         }
>     }
> 
>     public static void main(String[] args) throws Exception {
>         JPopupMenuSerializationTest test = new JPopupMenuSerializationTest();
>         test.testSerialization();
>     }
> 
>     public void testSerialization() throws Exception {
>         JPopupMenu popupMenu = new JPopupMenu();
>         byte[] data = serialize(popupMenu);
>         JPopupMenu copy = deserialize(data);
> 
>         test(copy);
>     }
> 
>     private void test(JPopupMenu jpm) {
>         JFrame frame = new JFrame("My frame");
>         final Container pane = frame.getContentPane();
>         pane.setLayout(new BorderLayout());
>         pane.add(new JTextField("", 20), BorderLayout.NORTH);
>         JButton btn = new JButton("Exit");
>         final Thread[] thr = new Thread[] { null };
>         btn.setAction(new AbstractAction() {
>             public void actionPerformed(ActionEvent ev) {
>                 System.exit(0);
>             }
>         });
>         btn.setText("Exit");
>         pane.add(btn, BorderLayout.SOUTH);
>         final JLabel label = new JLabel("Click here to invoke popup");
>         label.addMouseListener(new MouseAdapter() {
>             public void mouseReleased(MouseEvent e) {
>                 jpm.add("One");
>                 jpm.add("Two");
>                 jpm.add("Three");
>                 jpm.show(label,
>                         label.getLocationOnScreen().x,
>                         label.getLocationOnScreen().y);
>             }
> 
>             public void mousePressed(MouseEvent e) {
>                 Thread thr = new Thread(new MyThread(pane, label));
>                 thr.st...

Do we even care about serialisation as much?

What would be the use case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2242601894

From aivanov at openjdk.org  Wed Jul 30 13:08:58 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 30 Jul 2025 13:08:58 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v7]
In-Reply-To: <NqoLKH6_7G9Fwj7gNUYYXAz9Y7QXirrz4ZrF7giScNE=.c05b5998-c241-4149-81e5-f0fb9c7c564c@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <NqoLKH6_7G9Fwj7gNUYYXAz9Y7QXirrz4ZrF7giScNE=.c05b5998-c241-4149-81e5-f0fb9c7c564c@github.com>
Message-ID: <OeuFHx7rweHq8wposMcB6eM2YhfnKg1cg7PqLMNbdGo=.db701e66-f3fc-4025-9015-6364b73962c2@github.com>

On Wed, 30 Jul 2025 09:56:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
>> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
>> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Serialization fix

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 934:

> 932:     }
> 933: 
> 934:     private class Listener implements PropertyChangeListener,Serializable {

Suggestion:

    private final class AncestorListener implements PropertyChangeListener, Serializable {

Be more specific. Make the class `final` explicitly; it's not meant to be extended. Put a space after the comma.

src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 935:

> 933: 
> 934:     private class Listener implements PropertyChangeListener,Serializable {
> 935:         public void propertyChange(PropertyChangeEvent e) {

Add `@Override` annotation.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26407#pullrequestreview-3071424167
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2242610638
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2242623614

From aivanov at openjdk.org  Wed Jul 30 13:08:59 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 30 Jul 2025 13:08:59 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v6]
In-Reply-To: <ykq2tvTkukB5xhBWdhI7twC-xVKnWBl_kSwgC-F1ilc=.d0c40409-68dc-4695-aa66-08ea227444f1@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <aWx2YhEsiePSr1TwmFkwE9EbvrK4oBKXo3zvSE7xo4w=.3891bca7-53bf-415c-991f-7d55321c4274@github.com>
 <y14JDDFTEISesFRc7H_KRsz-hNAbhGGwhTnGJ_2sDe0=.9dbc9e1b-ea38-4f6f-ac6b-f71a1d2fa631@github.com>
 <c2V-6ZDF9g7sddWjdKZsr0ozeop3-QpPpzowvWZuk5k=.02a4f290-2f85-4557-8d82-59d0ad2f7e87@github.com>
 <4UqebAsi-WEmkX_Ngyi23eDLvIyvsH0VlR58UdDSAn8=.75c4f4f4-7df1-494e-a7d7-17125ef1b195@github.com>
 <E2AHJb6cDV0vetYEuAVsAX7gAnDLg9vnMCGx9VVaepo=.6adebba2-aacb-4496-ba3b-d9d9ac8105b9@github.com>
 <QAkuElS7L9kwqIiEXvtpkgE3kw3Kuh2a06V2m6GkNxk=.b287e92d-eea8-4816-aefe-92508b321b29@github.com>
 <8edaFrwzz4wTmP7dsJphHdhcLQNXNPficreToIbypYI=.f82f5fee-90d9-431b-950d-2a68da02d9ce@github.com>
 <ykq2tvTkukB5xhBWdhI7twC-xVKnWBl_kSwgC-F1ilc=.d0c40409-68dc-4695-aa66-08ea227444f1@github.com>
Message-ID: <Le1T89LR75giLFmJCu31TPZvkTS1v-7h8nOq1qDIsjE=.a6f57061-164a-4d21-93e5-671f122a26a6@github.com>

On Wed, 30 Jul 2025 12:59:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yes, it seems deserialized JPopupMenu fails hiding the popup menu owing to `propListener` not getting serialized.
>> 
>> Tried with modified testcase of yours and fixed in latest PR
>> 
>> 
>> import java.awt.*;
>> import java.awt.event.*;
>> import javax.swing.*;
>> import java.beans.PropertyChangeListener;
>> import java.io.*;
>> 
>> public class JPopupMenuSerializationTest {
>> 
>>     public static class MyThread implements Runnable {
>>         static Container box;
>>         static Component invo;
>> 
>>         public MyThread(Container cont, Component comp) {
>>             this.invo = comp;
>>             this.box = cont;
>>         }
>> 
>>         public void run() {
>>             System.out.println("Starting 3 second countdown...");
>>             try{
>>                 Thread.currentThread().sleep(3000);
>>             } catch (Exception e) {}
>>             System.out.println("Removing popup invoker from the container.");
>>             box.remove(invo);
>>             box.repaint();
>>         }
>>     }
>> 
>>     public static void main(String[] args) throws Exception {
>>         JPopupMenuSerializationTest test = new JPopupMenuSerializationTest();
>>         test.testSerialization();
>>     }
>> 
>>     public void testSerialization() throws Exception {
>>         JPopupMenu popupMenu = new JPopupMenu();
>>         byte[] data = serialize(popupMenu);
>>         JPopupMenu copy = deserialize(data);
>> 
>>         test(copy);
>>     }
>> 
>>     private void test(JPopupMenu jpm) {
>>         JFrame frame = new JFrame("My frame");
>>         final Container pane = frame.getContentPane();
>>         pane.setLayout(new BorderLayout());
>>         pane.add(new JTextField("", 20), BorderLayout.NORTH);
>>         JButton btn = new JButton("Exit");
>>         final Thread[] thr = new Thread[] { null };
>>         btn.setAction(new AbstractAction() {
>>             public void actionPerformed(ActionEvent ev) {
>>                 System.exit(0);
>>             }
>>         });
>>         btn.setText("Exit");
>>         pane.add(btn, BorderLayout.SOUTH);
>>         final JLabel label = new JLabel("Click here to invoke popup");
>>         label.addMouseListener(new MouseAdapter() {
>>             public void mouseReleased(MouseEvent e) {
>>                 jpm.add("One");
>>                 jpm.add("Two");
>>                 jpm.add("Three");
>>                 jpm.show(label,
>>                         label.getLocationOnScreen().x,
>>                         label.getLocationOnScreen().y);
>>             }
>> 
>>...
>
> Do we even care about serialisation as much?
> 
> What would be the use case?

Does the `invoker` instance serialise registered listeners?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2242626737

From prr at openjdk.org  Wed Jul 30 15:57:52 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 30 Jul 2025 15:57:52 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
 <uYfHEhGKDMGWqf5CNoe0N0v7FJCcHIBHpnC_9mvLKjw=.8834ac6c-b5d1-49e0-88b0-6ab8bf0a72f9@github.com>
Message-ID: <tigrzjZUpuHr_yZyQ8T_Gky5uwV1hxqU2bVdU8yIHzA=.b6839a0d-de57-4516-ad01-ac670f90d4e3@github.com>

On Tue, 29 Jul 2025 17:27:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
>> 
>> 
>> #ifndef PNG_LOONGARCH_LSX_OPT
>> # if defined(__loongarch_sx)
>> # define PNG_LOONGARCH_LSX_OPT 1
>> # else
>> # define PNG_LOONGARCH_LSX_OPT 0
>> # endif
>> #endif
>> 
>> 
>> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.
>
> If PNG_LOONGARCH_LSX_OPT is set to 0 it disables all those extra fns
> https://github.com/openjdk/jdk/pull/18964/files
> 
> So LGTM.

> Thanks for the review, @prrace. Is a second reviewer needed?

I think wait another day to see if anyone from the build team wants to look.
@magicus ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26501#issuecomment-3136926671

From aivanov at openjdk.org  Wed Jul 30 17:20:54 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 30 Jul 2025 17:20:54 GMT
Subject: RFR: 8364177: JDK fails to build due to undefined symbol in libpng
 on LoongArch64
In-Reply-To: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
References: <zfQQ3jqV-Vai2ZLss_DIgq0hF7bDjaFc0RhIi-RfbWI=.065a40c8-d1b4-45ef-88c8-80c8730b4b82@github.com>
Message-ID: <AI062rZ6EnBO1C4T1FrvyEF-c7GMmAGIM1BqNl1AGeU=.5372aeb9-2ce9-4bda-af8f-fa47dcead4d2@github.com>

On Mon, 28 Jul 2025 09:25:34 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> After [JDK-8329004](https://bugs.openjdk.org/browse/JDK-8329004), the following code was added.
> 
> 
> #ifndef PNG_LOONGARCH_LSX_OPT
> # if defined(__loongarch_sx)
> # define PNG_LOONGARCH_LSX_OPT 1
> # else
> # define PNG_LOONGARCH_LSX_OPT 0
> # endif
> #endif
> 
> 
> Some compilers on LoongArch64 platforms enable `__loongarch_sx`, which causes `PNG_LOONGARCH_LSX_OPT` to be defined and an undefined error occurs. Refer to [JDK-8078245](https://bugs.openjdk.org/browse/JDK-8078245), add `-DPNG_LOONGARCH_LSX_OPT=0` to `LIBSPLASHSCREEN_CFLAGS` flags.

Looks good to me too.

As Phil suggested, you should wait for a day or two if anyone from the build team takes a look.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26501#pullrequestreview-3072631176

From psadhukhan at openjdk.org  Thu Jul 31 02:20:45 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 31 Jul 2025 02:20:45 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v8]
In-Reply-To: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
Message-ID: <l1LiNetquNEkPnxusUPN8SD8zXS9xR7lOZG3zL-lfy0=.d1da6e50-dad9-4128-9186-022d9b29aad7@github.com>

> Issue is seen that a popup doesn't get closed when the component that invokes it, gets removed from the parent container.
> This is because the JPopupMenu does not listen to its invoker liefecycle thereby behaving as a standalone entity after creation.
> Fix is made to make sure popup listens to its invoker lifecycle by registering its PropertyChangeListener to the invoker and listens to the ["ancestor" property name ], https://github.com/openjdk/jdk/blob/441dbde2c3c915ffd916e39a5b4a91df5620d7f3/src/java.desktop/share/classes/javax/swing/JComponent.java#L4853-L4858 which will become null when removed, wherein we should dispose of the popup

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Rename listener class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26407/files
  - new: https://git.openjdk.org/jdk/pull/26407/files/fd4cdea2..e1e9e91f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26407&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26407&range=06-07

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/26407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26407/head:pull/26407

PR: https://git.openjdk.org/jdk/pull/26407

From psadhukhan at openjdk.org  Thu Jul 31 02:20:46 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 31 Jul 2025 02:20:46 GMT
Subject: RFR: 4938801: The popup does not go when the component is removed
 [v7]
In-Reply-To: <OeuFHx7rweHq8wposMcB6eM2YhfnKg1cg7PqLMNbdGo=.db701e66-f3fc-4025-9015-6364b73962c2@github.com>
References: <SpttywMRzwNi3jXGrUIOfW-RZ3jKCi0bGFRtKxeKj1Q=.6ccf49c3-0ab5-4d60-b520-ea393e03c00f@github.com>
 <NqoLKH6_7G9Fwj7gNUYYXAz9Y7QXirrz4ZrF7giScNE=.c05b5998-c241-4149-81e5-f0fb9c7c564c@github.com>
 <OeuFHx7rweHq8wposMcB6eM2YhfnKg1cg7PqLMNbdGo=.db701e66-f3fc-4025-9015-6364b73962c2@github.com>
Message-ID: <AwsPlcpx2zP5sAMBru2dbCIf_kaeN2uP8GLVdY5d6fw=.bc7e42f4-7484-4400-bf02-5daa6e6b1bec@github.com>

On Wed, 30 Jul 2025 13:02:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Serialization fix
>
> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 934:
> 
>> 932:     }
>> 933: 
>> 934:     private class Listener implements PropertyChangeListener,Serializable {
> 
> Suggestion:
> 
>     private final class AncestorListener implements PropertyChangeListener, Serializable {
> 
> Be more specific. Make the class `final` explicitly; it's not meant to be extended. Put a space after the comma.

ok

> src/java.desktop/share/classes/javax/swing/JPopupMenu.java line 935:
> 
>> 933: 
>> 934:     private class Listener implements PropertyChangeListener,Serializable {
>> 935:         public void propertyChange(PropertyChangeEvent e) {
> 
> Add `@Override` annotation.

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2244202043
PR Review Comment: https://git.openjdk.org/jdk/pull/26407#discussion_r2244202169

From psadhukhan at openjdk.org  Thu Jul 31 02:35:04 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 31 Jul 2025 02:35:04 GMT
Subject: RFR: 8159055: Clarify handling of null and invalid image data for
 ImageIcon constructors and setImage method [v24]
In-Reply-To: <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>
References: <SMQvqIFB5Vos7ZZqDC1PNEt3tOCbgwP-eE4nFSst40Y=.e1ea3227-7a12-4962-bdae-1c3c8e8ce9b4@github.com>
 <3FaU4hpR7m9n7ruRzfbp40YRPnCvC9OdbG5b0ZMqvas=.6bc1f18a-0103-40a8-b4ee-507fc1608fce@github.com>
 <-6NCEENBJlFkU9_51kTW-f02DqkE-kSbpF9DQ19cBzo=.bd3d7c35-8934-4e9e-904e-89e0dcb90bb4@github.com>
Message-ID: <S9Buvgb6fkfHndrB-I8Tvs9o-H3KcyFtZZ9ZP8yMFGA=.722fdce0-d95b-4c2f-840c-bd2fa5e90aa5@github.com>

On Tue, 29 Jul 2025 18:55:47 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Modify summary
>>  - Modify summary
>>  - Remove redundant fileName param
>
> src/java.desktop/share/classes/javax/swing/ImageIcon.java line 68:
> 
>> 66:  * If the image source parameter to a constructor or method is non-null,
>> 67:  * but does not reference valid accessible image data,
>> 68:  * no exceptions will be thrown but the image will be unset,
> 
> "will behave as if unset" ?
> or maybe 
> "will behave as if uninitialized " ?

@prrace Any objection to my suggestion of statement? I guess that is succinct and describe what's the end result!!
`no exceptions will be thrown but the image will behave as if unset/uninitialized/null` doesn't sound right in my opinion as then user need to know "how it would behave" when image is unset or null which is basically image icon not getting rendered so I thought to cut the chase and describe the final result

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25767#discussion_r2244215823

From psadhukhan at openjdk.org  Thu Jul 31 04:14:53 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 31 Jul 2025 04:14:53 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
 <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
Message-ID: <SFgzHGUAIICW4EOcwlQTNht3_Of8YlE9H7-ILbLcLFg=.bb6da4ca-5d72-47ec-85c1-b643161ee08b@github.com>

On Mon, 21 Jul 2025 16:52:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Remove finalize method from CStrike.java
>> 
>> This one is a bit odd in that there's already a Disposer used - and in fact it involves two classes
>> CStrikeDisposer.java and its subclass - the nested class CStrike.GlyphInfoCache
>> CStrike.GlyphInfoCache is tracking all the glyph image references.
>> 
>> CStrikeDisposer has the full set of constructors of its superclass - FontStrikeDisposer including support
>> for the native context
>> 
>> And if supplied, CStrikeDisposer will call the native method freeNativeScalerContext(long) to free the native context
>> but that native method does not exist !
>> And there's no CStrike.GlyphInfoCache constructor which allows it to be specified
>> 
>> So the fix is to add that and call the disposeNativeStrikePtr method instead.
>> 
>> I also rejigged things a little so nativeStrikePtr could be final which is supposed to help with the thread visibility.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8210765

Guess wildcard import and copyright year fix can be done..

src/java.desktop/macosx/classes/sun/font/CStrike.java line 99:

> 97: 
> 98:     public long getNativeStrikePtr() {
> 99:         return nativeStrikePtr;

Any reason this check was removed?
I see that initNativeStrikePtr will call createNativeStrikePtr which does this where there is no null check and it just returns what it gets so shouldn't we check it here?


awtStrike = [AWTStrike awtStrikeForFont:awtFont tx:glyphTx invDevTx:invDevTx style:style aaStyle:aaStyle]; // autoreleased

    if (awtStrike)
    {
        CFRetain(awtStrike); // GC
    }

JNI_COCOA_EXIT(env);
    return ptr_to_jlong(awtStrike);

-------------

PR Review: https://git.openjdk.org/jdk/pull/26397#pullrequestreview-3073923632
PR Review Comment: https://git.openjdk.org/jdk/pull/26397#discussion_r2244303469

From psadhukhan at openjdk.org  Thu Jul 31 05:25:03 2025
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 31 Jul 2025 05:25:03 GMT
Subject: RFR: 4870789: RFE: UIDefaults.getUIError() hides real error
Message-ID: <KmIIfh9U9Ao7EVepMjO5aNKS1i1LUS72TjmaVZ6FyCU=.59610038-c1a7-489d-822f-6a91094fb413@github.com>

`UIDefaults.getUIError` method is invoked when an exception occurred in UI code but this method hides the underlying exception, this method could be more useful if the original exception is passed as argument and used as the cause of the Error thrown from `getUIError` body

-------------

Commit messages:
 - 4870789: RFE: UIDefaults.getUIError() hides real error

Changes: https://git.openjdk.org/jdk/pull/26567/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4870789
  Stats: 14 lines in 3 files changed: 1 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/26567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26567/head:pull/26567

PR: https://git.openjdk.org/jdk/pull/26567

From rgupta at openjdk.org  Thu Jul 31 05:37:59 2025
From: rgupta at openjdk.org (Ravi Gupta)
Date: Thu, 31 Jul 2025 05:37:59 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v6]
In-Reply-To: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
Message-ID: <chMDIBRzIshsf1RR9yTEFsrDoN0mxk76BdG8GsweGxk=.a6836859-e861-4e21-ae87-f16aeb6a52fa@github.com>

> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
> 
> 
>  finally {
>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>         }
>     public static void disposeFrame() {
>         if (frame != null) {
>             frame.dispose();
>             frame = null;
>         }
>     }

Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:

  8361067: Review Comments fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26043/files
  - new: https://git.openjdk.org/jdk/pull/26043/files/a45a9bf7..995c93b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26043&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26043&range=04-05

  Stats: 21 lines in 1 file changed: 0 ins; 12 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26043/head:pull/26043

PR: https://git.openjdk.org/jdk/pull/26043

From azvegint at openjdk.org  Thu Jul 31 06:07:04 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 31 Jul 2025 06:07:04 GMT
Subject: Integrated: 8361524: [XWayland] possible JavaFX interop hang
In-Reply-To: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
References: <Rq_JoSSDYj6e1c8wIb7ctwNRLRE_E3SK2j0FIpYXuE0=.e9003994-32db-4fd4-9788-56670d11e2d9@github.com>
Message-ID: <G-wGOlbg6S7bIK9a-GJerbTbf9fm7u0A70ewgsV9T6g=.75091c69-2210-4e2c-9aa0-3664ec10dbad@github.com>

On Mon, 7 Jul 2025 21:41:18 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Callbacks in the `src/java.desktop/unix/native/libawt_xawt/awt/screencast_portal.c` file normally have the following pattern:
> 
> 
> helper->isDone = TRUE;
> callbackEnd();
> // return;
> 
> 
> Failing to call `callbackEnd()` could result in a hang if another GTK loop is running (e.g., JavaFX see https://github.com/openjdk/jdk/pull/22131#issue-2660482472).
> 
> This fix corrects this flaw.

This pull request has now been integrated.

Changeset: 05c63e80
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05c63e80091d554625c5b6fc8c9f6973ef19ec4f
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8361524: [XWayland] possible JavaFX interop hang

Reviewed-by: psadhukhan, serb, prr, kizune, kcr

-------------

PR: https://git.openjdk.org/jdk/pull/26172

From dnguyen at openjdk.org  Thu Jul 31 06:24:59 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 31 Jul 2025 06:24:59 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline
In-Reply-To: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
Message-ID: <ETBp0MhecYGij9zjswjXpsLMMlYuFmjtcxNqMgRLB2M=.f3393500-8e3c-4cbe-b591-7c845e038d5f@github.com>

On Wed, 30 Jul 2025 06:22:56 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
> Test instruction updated to reflect the desired behaviour .

Agreed that the instructions need to be updated for this. Maybe rephrase the new segment to read a bit smoother.

test/jdk/javax/swing/SwingUtilities/bug4967768.java line 45:

> 43:             ALT key to activate the mnemonic to be visible.
> 44:             Once ALT key is pressed, the "p" letter
> 45:             is underlined at the bottom of the instruction frame.

Suggestion:

            For Windows and GTK Look and Feel, you will need to 
            press the ALT key to make the mnemonic visible.
            Once the ALT key is pressed, the letter "p" will be
            underlined at the bottom of the instruction frame.

-------------

Changes requested by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26546#pullrequestreview-3074112147
PR Review Comment: https://git.openjdk.org/jdk/pull/26546#discussion_r2244455122

From abhiscxk at openjdk.org  Thu Jul 31 07:28:36 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 31 Jul 2025 07:28:36 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
Message-ID: <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>

> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
> Test instruction updated to reflect the desired behaviour .

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  minor text instruction update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26546/files
  - new: https://git.openjdk.org/jdk/pull/26546/files/f5248f70..ca742746

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26546&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26546&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26546.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26546/head:pull/26546

PR: https://git.openjdk.org/jdk/pull/26546

From abhiscxk at openjdk.org  Thu Jul 31 07:28:36 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 31 Jul 2025 07:28:36 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <ETBp0MhecYGij9zjswjXpsLMMlYuFmjtcxNqMgRLB2M=.f3393500-8e3c-4cbe-b591-7c845e038d5f@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <ETBp0MhecYGij9zjswjXpsLMMlYuFmjtcxNqMgRLB2M=.f3393500-8e3c-4cbe-b591-7c845e038d5f@github.com>
Message-ID: <4RgrvNwHMxuUVkGTe85VV6xPhPJA_QKBTOZBUP4PyBc=.ec5cf59c-15b9-4d45-ad64-b4c3722e5259@github.com>

On Thu, 31 Jul 2025 06:21:02 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor text instruction update
>
> test/jdk/javax/swing/SwingUtilities/bug4967768.java line 45:
> 
>> 43:             ALT key to activate the mnemonic to be visible.
>> 44:             Once ALT key is pressed, the "p" letter
>> 45:             is underlined at the bottom of the instruction frame.
> 
> Suggestion:
> 
>             For Windows and GTK Look and Feel, you will need to 
>             press the ALT key to make the mnemonic visible.
>             Once the ALT key is pressed, the letter "p" will be
>             underlined at the bottom of the instruction frame.

Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26546#discussion_r2244573135

From abhiscxk at openjdk.org  Thu Jul 31 10:39:02 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 31 Jul 2025 10:39:02 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v6]
In-Reply-To: <chMDIBRzIshsf1RR9yTEFsrDoN0mxk76BdG8GsweGxk=.a6836859-e861-4e21-ae87-f16aeb6a52fa@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <chMDIBRzIshsf1RR9yTEFsrDoN0mxk76BdG8GsweGxk=.a6836859-e861-4e21-ae87-f16aeb6a52fa@github.com>
Message-ID: <49u_qL7v__jZ-RjPM4lK96RxiQ6MtZ8OZmcelXKfrdY=.c3017a36-4d7c-45f4-9bc7-d7a74640ef4b@github.com>

On Thu, 31 Jul 2025 05:37:59 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: Review Comments fix

Looks good to me now. Just a minor correction can be done in summary.

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 28:

> 26:  * @key headful
> 27:  * @bug 6315717
> 28:  * @summary verifies that drag events are coming for every button if the property is set to true

Summary can be re-phrased to --

Verifies that mouse drag events received for every button if the property is set to true

-------------

Marked as reviewed by abhiscxk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26043#pullrequestreview-3074866511
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2245007756

From tr at openjdk.org  Thu Jul 31 13:37:56 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 31 Jul 2025 13:37:56 GMT
Subject: RFR: 8361190: Test
 java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java fails on MacOS X
In-Reply-To: <3NnGZljkl_7n671ESgZ9bZM4Kz7qZEpA0M4Yk5H_L7U=.241d7e1c-a061-4602-9c30-b577bcb0df7e@github.com>
References: <h5HpAx4LPAG3aueD42V6Vd3qwQcDwOoCPQzFbKKTunM=.efa6043d-f1ea-491b-83ce-7417f7797c07@github.com>
 <3NnGZljkl_7n671ESgZ9bZM4Kz7qZEpA0M4Yk5H_L7U=.241d7e1c-a061-4602-9c30-b577bcb0df7e@github.com>
Message-ID: <g6LDeLddi1TOxtIqPpXNR2Go1Mpj5Ge03WE_MzuPh1M=.8f05a55d-06cb-44ea-94d5-c9891f7e93f5@github.com>

On Fri, 18 Jul 2025 08:12:16 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> I will combine this PR with #26162 and i will see if other PRs could be merged as well.

Please close these PR's once you raise a single PR with combined fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26196#issuecomment-3140007022

From ngubarkov at openjdk.org  Thu Jul 31 13:38:33 2025
From: ngubarkov at openjdk.org (Nikita Gubarkov)
Date: Thu, 31 Jul 2025 13:38:33 GMT
Subject: RFR: 8364434: Inconsistent BufferedContext state after GC
Message-ID: <qZAYN9N5OTdSKC_7HZRDyCe_Oejj0etuytJs_a7RgOI=.9ce6e9b6-83b8-4030-bd8b-fd4bf8f16bde@github.com>

For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.

Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.

-------------

Commit messages:
 - 8364434: Inconsistent BufferedContext state after GC

Changes: https://git.openjdk.org/jdk/pull/26576/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26576&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8364434
  Stats: 37 lines in 1 file changed: 12 ins; 2 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/26576.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26576/head:pull/26576

PR: https://git.openjdk.org/jdk/pull/26576

From tr at openjdk.org  Thu Jul 31 13:48:58 2025
From: tr at openjdk.org (Tejesh R)
Date: Thu, 31 Jul 2025 13:48:58 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
Message-ID: <2s1wmxROMbswI-vhhS8_-JpNuJ3ZnTE9n0ACPmw3E0k=.4809f5b7-e5b8-4dec-a96f-d47999ab742e@github.com>

On Thu, 31 Jul 2025 07:28:36 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
>> Test instruction updated to reflect the desired behaviour .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor text instruction update

If I am right, the main bug is about underline drawing and not about mnemonic. Yet mnemonic is used to check underline drawing under the string, I guess you can think of using the code mentioned in [JDK-4967768](https://bugs.openjdk.org/browse/JDK-4967768) in the test which would be fine for all L&F.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26546#pullrequestreview-3075514372

From abaya at openjdk.org  Thu Jul 31 14:15:12 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 31 Jul 2025 14:15:12 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux [v2]
In-Reply-To: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
Message-ID: <ddT_Nfs7vrGcLvXOk-TSno6SWb5fuKwofQZzaOG7EK8=.40421506-12f7-4c8a-9256-c544b25a22cb@github.com>

> **Analysis:**
> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
> 
> **Proposed Fix:**
> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to BogusFocusableWindowState.java from

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26298/files
  - new: https://git.openjdk.org/jdk/pull/26298/files/9cfd22da..2019239f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26298&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26298&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26298/head:pull/26298

PR: https://git.openjdk.org/jdk/pull/26298

From abaya at openjdk.org  Thu Jul 31 14:21:33 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 31 Jul 2025 14:21:33 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux [v3]
In-Reply-To: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
Message-ID: <ZTbsjNekjUeeEErX1m2nsUN_9aqVvHvc97ofLGVqn8w=.abe34dd2-fea6-4c62-8cc7-8d90c4d3efe5@github.com>

> **Analysis:**
> The getFocusableWindowState() method is not intended to modify the configuration; doing so can cause recursive re-entry on Linux.
> 
> **Proposed Fix:**
> We are intentionally overriding getFocusableWindowState() to allow it to change the configuration, in order to verify that calling getScreenImOn() for ownerless windows does not throw any exceptions.
> To prevent recursive re-entry, we use a flag to ensure that getFocusableWindowState() is executed only once

Anass Baya has updated the pull request incrementally with one additional commit since the last revision:

  Do not update Focusability when it is not needed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26298/files
  - new: https://git.openjdk.org/jdk/pull/26298/files/2019239f..f33a7229

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26298&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26298&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/26298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26298/head:pull/26298

PR: https://git.openjdk.org/jdk/pull/26298

From abaya at openjdk.org  Thu Jul 31 14:21:33 2025
From: abaya at openjdk.org (Anass Baya)
Date: Thu, 31 Jul 2025 14:21:33 GMT
Subject: RFR: 8361521 : BogusFocusableWindowState.java fails with
 StackOverflowError on Linux
In-Reply-To: <ek7aLf2QVQEnSsW-6w9Sel4n_Vu1fv-v6DYwAJzkQEQ=.d85ac524-74a0-478e-a6cf-a6a790d4b22e@github.com>
References: <XA0gVsLOCSRXSp06GCPPqyMMB3l7hT0_q8CV8CE5zSk=.a740ce47-9673-4739-b940-0467914953d6@github.com>
 <ek7aLf2QVQEnSsW-6w9Sel4n_Vu1fv-v6DYwAJzkQEQ=.d85ac524-74a0-478e-a6cf-a6a790d4b22e@github.com>
Message-ID: <75cF1znIlzfOry_Kg5Po4NY-jgfL2XJ40HHVgpVlYPg=.de5d4ffa-88e7-4847-8047-7df2b7689764@github.com>

On Tue, 15 Jul 2025 02:52:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I do not think this is a bug in the test, the jdk should survive this.

Hello @mrserb, 
Thank you for your reivew.
To ensure Linux survives that, I think we need to avoid updating focusability when it is not necessary.

--- XWindowPeer.java
+++ XWindowPeer.java
     @Override
     public void setVisible(boolean vis) {
+        if(isVisible() == vis) {
+            return;
+        }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26298#issuecomment-3140169438

From dnguyen at openjdk.org  Thu Jul 31 15:28:54 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 31 Jul 2025 15:28:54 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <2s1wmxROMbswI-vhhS8_-JpNuJ3ZnTE9n0ACPmw3E0k=.4809f5b7-e5b8-4dec-a96f-d47999ab742e@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
 <2s1wmxROMbswI-vhhS8_-JpNuJ3ZnTE9n0ACPmw3E0k=.4809f5b7-e5b8-4dec-a96f-d47999ab742e@github.com>
Message-ID: <dxkWt8VODuyidUIFl5eVxjIqtLBvpl-klFO20st_KN8=.750712e5-c97b-432b-af06-fab3b173fa8d@github.com>

On Thu, 31 Jul 2025 13:46:32 GMT, Tejesh R <tr at openjdk.org> wrote:

> If I am right, the main bug is about underline drawing and not about mnemonic. Yet mnemonic is used to check underline drawing under the string, I guess you can think of using the code mentioned in [JDK-4967768](https://bugs.openjdk.org/browse/JDK-4967768) in the test which would be fine for all L&F.

Good point. I second this if possible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26546#issuecomment-3140403537

From abhiscxk at openjdk.org  Thu Jul 31 16:23:54 2025
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 31 Jul 2025 16:23:54 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <dxkWt8VODuyidUIFl5eVxjIqtLBvpl-klFO20st_KN8=.750712e5-c97b-432b-af06-fab3b173fa8d@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
 <2s1wmxROMbswI-vhhS8_-JpNuJ3ZnTE9n0ACPmw3E0k=.4809f5b7-e5b8-4dec-a96f-d47999ab742e@github.com>
 <dxkWt8VODuyidUIFl5eVxjIqtLBvpl-klFO20st_KN8=.750712e5-c97b-432b-af06-fab3b173fa8d@github.com>
Message-ID: <lI9u4yY3DXCiuA6xGQseQgCH7fBnM6mulHOwuTP8vvY=.9204f0c5-9d3f-4e9b-ae64-0fc2f6ab20e1@github.com>

On Thu, 31 Jul 2025 15:26:46 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> > If I am right, the main bug is about underline drawing and not about mnemonic. Yet mnemonic is used to check underline drawing under the string, I guess you can think of using the code mentioned in [JDK-4967768](https://bugs.openjdk.org/browse/JDK-4967768) in the test which would be fine for all L&F.
> 
> Good point. I second this if possible.

Yes, the main bug is about the underline drawing and not mnemonic but the underline i.e. mnemonic visibility depends on the platform the test is running. It depends on the current L&F as well. In case of Metal, Motif and Nimbus, the underline is visible always whereas if the test ran with Windows or GTK L&F, underline visibility depends on the how the underlying platform handle the underline. If the underline drawing is invisible then I don't see any way to verify it's position.

>I guess you can think of using the code mentioned in [JDK-4967768](https://bugs.openjdk.org/browse/JDK-4967768) in the test which would be fine for all L&F.

The code you mentioned is already implemented in [SwingUtilities's drawStringUnderlineCharAt](https://github.com/kumarabhi006/jdk/blob/04c0b130f09c093797895cc928fe020d7e584cb9/src/java.desktop/share/classes/sun/swing/SwingUtilities2.java#L694) method and I checked on Windows and macOS that this code path is executed and that impact the underline drawing. If it is commented then there is no underline drawing for the mnemonics and vice-versa.

The underline drawing is correct as it has drawn just below the baseline and not below the character "P".

So, I think the fix requires an instruction change to let the tester know that the "ALT" key press is a requirement to make the mnemonic visible and then the underline position can be verified further.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26546#issuecomment-3140571811

From kizune at openjdk.org  Thu Jul 31 16:26:56 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 31 Jul 2025 16:26:56 GMT
Subject: RFR: 8339791: Refactor MiscUndecorated/ActiveAWTWindowTest.java
In-Reply-To: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>
References: <lTkFPN34j_fpVm5-8-KVNtQLqQlYrQVrYKzm0BDzV-I=.cd3d9a89-e26d-4690-80fe-3d6103213a0f@github.com>
Message-ID: <JQb1C0yKejFuZVa9B-hX20jN4ic13jiWalu8r902fW0=.fabc1b9f-8565-4ef8-9a75-63029c90388f@github.com>

On Fri, 25 Jul 2025 05:33:31 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> The java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java test uses object monitors and wait/notify to synchronise actions in the test.
> 
> Using CountDownLatch could make the test simpler, shorter, clearer.
> Tested the code on a windows-x64, macos-x64 and lnux-x64 machines and the test is working as expected.

test/jdk/java/awt/Frame/MiscUndecorated/ActiveAWTWindowTest.java line 59:

> 57:     private static final CountDownLatch windowActivatedLatch = new CountDownLatch(1);
> 58:     private static final CountDownLatch windowDeactivatedLatch = new CountDownLatch(1);
> 59:     private static final CountDownLatch windowFocusGainedLatch = new CountDownLatch(1);

I see where we decrement this latch but i do not see where we check it or wait on it. Is it really needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26471#discussion_r2245845824

From dnguyen at openjdk.org  Thu Jul 31 16:33:55 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 31 Jul 2025 16:33:55 GMT
Subject: RFR: 8361191: Test
 java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java fails on MacOS X
In-Reply-To: <Z_B9aJ4T479Bk9GxIR4eI35FZLpqYYcLarqrHru98VU=.f1beedce-3dd2-41a5-bc5c-f2a9b4565c3a@github.com>
References: <Z_B9aJ4T479Bk9GxIR4eI35FZLpqYYcLarqrHru98VU=.f1beedce-3dd2-41a5-bc5c-f2a9b4565c3a@github.com>
Message-ID: <UXtUK6WTpfn0irHDWWFXzkrgiv9WRvyMoluZwAzE4-Q=.8dbb0a45-c411-4e67-bf50-8f1d83b46421@github.com>

On Tue, 8 Jul 2025 15:23:03 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

> Fixes failed test by disabling heavyweight component in ItemListener.

As mentioned in https://github.com/openjdk/jdk/pull/26196, can you also combine this with the others into one PR? This PR has only the removal of the test from the ProblemList and a single line of a minor change to the test.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26190#pullrequestreview-3076132196

From prr at openjdk.org  Thu Jul 31 19:33:56 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 31 Jul 2025 19:33:56 GMT
Subject: RFR: 4870789: RFE: UIDefaults.getUIError() hides real error
In-Reply-To: <KmIIfh9U9Ao7EVepMjO5aNKS1i1LUS72TjmaVZ6FyCU=.59610038-c1a7-489d-822f-6a91094fb413@github.com>
References: <KmIIfh9U9Ao7EVepMjO5aNKS1i1LUS72TjmaVZ6FyCU=.59610038-c1a7-489d-822f-6a91094fb413@github.com>
Message-ID: <VK4RjRS_P2CwzSGi9aIy4LrpIFl7Pe6FrAiwrg49Gtw=.eab3869a-9509-4ebd-abf3-4b93bf58e84d@github.com>

On Thu, 31 Jul 2025 05:20:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `UIDefaults.getUIError` method is invoked when an exception occurred in UI code but this method hides the underlying exception, this method could be more useful if the original exception is passed as argument and used as the cause of the Error thrown from `getUIError` body

This is an incompatible change. 
All it does is break any code that calls getUIError()
And I notice no JDK code calls this so I am not seeing any point to this change.
I think this RFE should be closed as will-not-fix.

-------------

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26567#pullrequestreview-3076662716

From prr at openjdk.org  Thu Jul 31 19:49:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 31 Jul 2025 19:49:54 GMT
Subject: RFR: 8210765: Remove finalize method in CStrike.java [v2]
In-Reply-To: <SFgzHGUAIICW4EOcwlQTNht3_Of8YlE9H7-ILbLcLFg=.bb6da4ca-5d72-47ec-85c1-b643161ee08b@github.com>
References: <vOd2X5FDWzclDrqVkaBgkNGPEEVRP-6j7ttMKaDQPRc=.dc18ebf0-6fc0-4b23-872d-ae397a847728@github.com>
 <wNxQ3XK6zYmI5ECN_RNWC2qjpcvazrR5n8XV-VLZwXY=.3f08b628-c601-48ea-8b43-1a6cec6a14d9@github.com>
 <SFgzHGUAIICW4EOcwlQTNht3_Of8YlE9H7-ILbLcLFg=.bb6da4ca-5d72-47ec-85c1-b643161ee08b@github.com>
Message-ID: <0AugtjRm8JvkkVaQfhEZWkc4Sr4q3jVsQ9WTbJ1DXSc=.98ed7882-3d25-461f-9efd-43683de2d059@github.com>

On Thu, 31 Jul 2025 04:10:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8210765
>
> src/java.desktop/macosx/classes/sun/font/CStrike.java line 99:
> 
>> 97: 
>> 98:     public long getNativeStrikePtr() {
>> 99:         return nativeStrikePtr;
> 
> Any reason this check was removed?
> I see that initNativeStrikePtr will call createNativeStrikePtr which does this where there is no null check and it just returns what it gets so shouldn't we check it here?
> 
> 
> awtStrike = [AWTStrike awtStrikeForFont:awtFont tx:glyphTx invDevTx:invDevTx style:style aaStyle:aaStyle]; // autoreleased
> 
>     if (awtStrike)
>     {
>         CFRetain(awtStrike); // GC
>     }
> 
> JNI_COCOA_EXIT(env);
>     return ptr_to_jlong(awtStrike);

And if it is 0, what would you do ?
Previously 0 meant it hadn't yet been initialized. Now it is always initialized.

You'd need to return it anyway even it was zero.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26397#discussion_r2246246622

From dnguyen at openjdk.org  Thu Jul 31 19:55:01 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 31 Jul 2025 19:55:01 GMT
Subject: RFR: 8362067: Remove unnecessary List.contains key from
 SpringLayout.Constraints.pushConstraint
In-Reply-To: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
References: <J1xxM38N-3IKkYpXMS2yoItEVV3P6HJzhlZ5m6LFRoY=.4e533e37-0dc4-4b44-b705-d93ecf4bbcc8@github.com>
Message-ID: <YO6j9ebIJwAREe9FYHTpf6sGX5jmlNTUg5txF5ddvVE=.9221a5ed-0189-46af-b766-08657c84bc6e@github.com>

On Thu, 24 Apr 2025 14:53:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is no need to call `List.contains` before `List.remove` call.
> `history` is an either `horizontalHistory` or `verticalHistory`. Both of them are ArrayList's.

Seems perfectly OK to me. `remove` inherently handles the cases where `name` doesn't occur, so `contains` is redundant. Built the change fine. Ran a sample test to confirm everything works as expected. LGTM after wildcard import change.

src/java.desktop/share/classes/javax/swing/SpringLayout.java line 32:

> 30: import java.awt.Insets;
> 31: import java.awt.LayoutManager2;
> 32: import java.util.*;

Can you expand the wildcard import since we're touching this part of the file anyway?


package javax.swing;

import java.awt.Component;
import java.awt.Container;
import java.awt.Dimension;
import java.awt.Insets;
import java.awt.LayoutManager2;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashMap;
import java.util.HashSet;
import java.util.List;
import java.util.Map;
import java.util.Set;

-------------

Changes requested by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24852#pullrequestreview-3076709112
PR Review Comment: https://git.openjdk.org/jdk/pull/24852#discussion_r2246251589

From prr at openjdk.org  Thu Jul 31 20:04:57 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 31 Jul 2025 20:04:57 GMT
Subject: RFR: 8158801: [TEST_BUG] Mixing tests fail because of focus
 workaround trick [v12]
In-Reply-To: <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
References: <sU85U4hlcLErgWJaAmeelx1x6SjY_BIMU8T-aAeSjno=.77cd601e-01c1-411b-8fab-f8abe6e5170f@github.com>
 <U8E8iO_IYi70YtJCbfQ0Yp_9VqXob9lOQda5DqM4U3o=.13837290-e650-4203-a969-898656385064@github.com>
Message-ID: <4gcx7io3xNfusJ0OtErbmzQ5n2ywgvMk7Iz6jMXSHsI=.8437e6d1-aa15-4d19-aebc-4bb1ddbb3af4@github.com>

On Wed, 23 Jul 2025 14:47:41 GMT, Khalid Boulanouare <duke at openjdk.org> wrote:

>> Many Mixing tests failed because the work around click lands on the minimizing area in the window control and causes the tests to fail.
>> 
>> This fix changes the width of base frames which allows most of tests to pass.
>
> Khalid Boulanouare 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 21 additional commits since the last revision:
> 
>  - Removes not needed component frace ancestor.
>  - Problem unlists passed tests
>  - Uses frame requestFocus instead of robot clicks for focus
>  - Removes extra Robot waitForIdle
>  - Merge branch 'openjdk:master' into jdk-8158801
>  - Restores copyright year for tests not updated
>  - Removes some tests from problem list
>  - Uses request frame focus instead of Robot clicks to request frame focus
>  - Revert "Changes Frame width to 300, uses protected constants for all base tests frame sizes"
>    
>    This reverts commit b6558c79a129837c3d8d92cdc99d9417e630126d.
>  - Revert "Removes passed tests from problem list"
>    
>    This reverts commit 2f9be981c785ba40574fc5710c0330fb3abc60d2.
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/05aa0f9b...b558508f

I see that you filed all these bugs
https://bugs.openjdk.org/browse/JDK-8361188
https://bugs.openjdk.org/browse/JDK-8361189
https://bugs.openjdk.org/browse/JDK-8361190
https://bugs.openjdk.org/browse/JDK-8361191
https://bugs.openjdk.org/browse/JDK-8361192
https://bugs.openjdk.org/browse/JDK-8361193
https://bugs.openjdk.org/browse/JDK-8361195

and not one of them has a description or evaluation.
And the dependencies suggest they aren't completely unrelated.
Also you will be making "N" problem list updates ..
This would have been easier for people to follow and you to manage if it was ONE bug and ONE PR.
I suggest you close all but one and deal with them all together.

Also be a bit more clear in why the change fixes it - I read comments like 
"Changes heavyweight color to white, for the test to pass." - What was the problem and why does that fix it ?
"Fixes failed test by disabling heavyweight component in ItemListener." - same issues.

I won't repeat everything like that but I need to be confident that you've understood the problem and can explain the fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25971#issuecomment-3141187795

From dnguyen at openjdk.org  Thu Jul 31 20:08:57 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 31 Jul 2025 20:08:57 GMT
Subject: RFR: 8357687: Remove unnecessary Map.containsKey from
 GraphicsEnvironment implementations
In-Reply-To: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
References: <1uiKqIpG8uZ6YKrglYBxK7nMYaqioOirqfiRAp5z7Dw=.813063e1-e218-4794-8bc1-fd8f543c4a74@github.com>
Message-ID: <jsQsaCbPaNetbIKrzNwnNCANSY5Nm4hTtFxIQcC6z60=.a340caf9-2466-4086-b133-687bf5e41855@github.com>

On Sun, 27 Apr 2025 21:04:34 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `devices` contains only non-null values. It means instead of separate `containsKey` call we can just call `HashMap.get` and then compare result with `null`.

I do agree that this is probably a subjective change. I think both are fairly clear and there's basically no impact to code performance I'd imagine. In my opinion, the old code's `containsKey` is slightly easier to follow than `d != null` but there's barely any difference.

Since I just reviewed https://github.com/openjdk/jdk/pull/24852 which is similar, I'll follow the same logic and agree with the change here too.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24907#pullrequestreview-3076745122

From prr at openjdk.org  Thu Jul 31 20:19:02 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 31 Jul 2025 20:19:02 GMT
Subject: RFR: 8361067: Test ExtraButtonDrag.java requires frame.dispose in
 finally block [v6]
In-Reply-To: <chMDIBRzIshsf1RR9yTEFsrDoN0mxk76BdG8GsweGxk=.a6836859-e861-4e21-ae87-f16aeb6a52fa@github.com>
References: <G7a2tVOeZvILvjRA4Db6xyHoT8_c9eLa_tpqj5gTfcM=.79ce3962-ce43-4353-bfb4-0040486afd24@github.com>
 <chMDIBRzIshsf1RR9yTEFsrDoN0mxk76BdG8GsweGxk=.a6836859-e861-4e21-ae87-f16aeb6a52fa@github.com>
Message-ID: <VE8hrTOgcy2nqrvKMKf_reVqsSKvsNX-Tbm2bLONPTo=.bf382a21-1e57-489d-9398-429ea0abb4e5@github.com>

On Thu, 31 Jul 2025 05:37:59 GMT, Ravi Gupta <rgupta at openjdk.org> wrote:

>> Test test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java left debris on system whenever fails its required frame.dispose() in finally block.
>> 
>> 
>>  finally {
>>             EventQueue.invokeAndWait(ExtraButtonDrag::disposeFrame);
>>         }
>>     public static void disposeFrame() {
>>         if (frame != null) {
>>             frame.dispose();
>>             frame = null;
>>         }
>>     }
>
> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361067: Review Comments fix

Marked as reviewed by prr (Reviewer).

test/jdk/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java line 123:

> 121:                             + " : dragged = " + dragged);
> 122:                     }
> 123:                 } else { // WToolkit

And macOS ?
Seems like this should be (1) X, (2) everything else ?
And I think that checking the Toolkit like this is iffy.
When we get to Wayland it will be WLToolkit on Linux and the test will do the wrong thing.
Yes, I am assuming that this aspect of Wayland will be X compatible ...
This is pre-existing so I leave it up to you but I'd prefer to have a check that doesn't use the name of an implementation class if there's an alternative. Like just checking if this is Linux.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26043#pullrequestreview-3076765605
PR Review Comment: https://git.openjdk.org/jdk/pull/26043#discussion_r2246293381

From prr at openjdk.org  Thu Jul 31 21:02:58 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 31 Jul 2025 21:02:58 GMT
Subject: RFR: 8359380: Rework deferral profile logic after JDK-8346465
In-Reply-To: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
References: <grWB7xCw_Qczyjr3QjJyYaSxENgkbNaGxc_5xpc9qL8=.0d022ebf-5cec-457e-8ec7-fc82983dce65@github.com>
Message-ID: <30WYs6jUCxCyAzXMXhqU1XguXI7QFzsVTObZjQF6ieE=.8882b1ae-d345-4095-8871-1c1651432278@github.com>

On Tue, 8 Jul 2025 05:26:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.
> 
> After [JDK-8346465](https://bugs.openjdk.org/browse/JDK-8346465) all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.
> 
> This patch includes two changes:
> 
> 1.  We [stop](https://github.com/openjdk/jdk/pull/26179/commits/dea4d8cd2a2450841469a289824281142bccacce) discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.
> 
> 2.  While implementing the logic above I noticed a [workaround](https://github.com/openjdk/jdk/pull/26179/commits/b40f97cddca3b260761553a1395ad2bac09b5fb6) introduced for [JDK-8272860](https://bugs.openjdk.org/browse/JDK-8272860) no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I?ve added a new test case that specifically verifies this behavior.

This looks OK, but I'm waiting for a full test run to complete.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26179#pullrequestreview-3076868370

From dnguyen at openjdk.org  Thu Jul 31 23:55:54 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 31 Jul 2025 23:55:54 GMT
Subject: RFR: 8361298: SwingUtilities/bug4967768.java fails where character
 P is not underline [v2]
In-Reply-To: <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
References: <7qTkbGu-T5xT0acetyZJjHkekEaJQfLoAzkQfYAWLTc=.b98e5daf-c7e9-4376-bb61-b12555eccdc1@github.com>
 <hC3u5dY_8Gu8Wwcs-1Gus1Nb2_56QXQKCXw9blDgrHk=.3b51e4a3-64e0-44be-a162-c88707dab0da@github.com>
Message-ID: <W0X1eepG3HgTFfBrT2KlyBUoghoEqrN3ZMBNocUzTTU=.7cc0601f-2419-40c8-9177-5c2df8eb9f02@github.com>

On Thu, 31 Jul 2025 07:28:36 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> For Windows and GTK L&F, mnemonic is visible when ALT key is pressed.
>> Test instruction updated to reflect the desired behaviour .
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor text instruction update

This way still displays an underline for the mnemonic so I'm fine with just the instruction change.

-------------

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26546#pullrequestreview-3077184689