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